WebQuerySave magic

In my current assignment (web, R7 server, R6.5 client), it is decided that users should have no ability to use the back button in the browser.
This is accomplished by inserting following line in JS Header:
if (history.length > 0) { history.go(+1) }

However, for validation and workflow, we also want to rely on the security of the server (WebQuerySave, lotusscript); not javascript: in this project that may nog be secure enough!

Has anyone found a way to perfectly combine these two? We are continuously having trouble.

If validation fails (new or existing document), we need to go back to the open document as it was and temporarily avoid the history.go(+1). Once there, we should prevent going forward and ending up at the validation result again. Somewhat later in time, after succesfully submitting the document, both pages in history should forward the user back to the most recent page.

Could anyone reveil his/her secret recipe? Or post a little demo that we can examine?
LVL 13
Who is Participating?
No, I did mean to mention that I was selectively ignoring the back button issue, but as long as you are good with the placement of that code, I was thinking it would be OK.  I've had better success and consistency with $$Return (off the top of my head I forget the issue with the print statement in the WQS).
Here is what I would try (I've often thought about this, but have never implemented it)...

1) In WebQueryOpen, make a hidden ('Draft') copy of the 'Original' document in the back-end.  Make sure that the 'Draft' copy has the UNID of the 'Original' saved in an item.

2) Force Domino to serve up the 'Draft' document instead of the 'Original'.

3) In the 'Draft' form's WebQuerySave, validate the document.  If it is invalid, save error messages in a hidden field, save the document, and re-serve up the 'Draft'.

4) Once the document passes the validation code, simply update the 'Original' from the 'Draft' and delete the 'Draft'.
Sjef BosmanGroupware ConsultantCommented:
That's a problem that needs some reflection... which I'm going to do in 5 minutes...

As a first thought: if JavaScript is permitted, how about using the onbeforeunload event on your page? It probably won't prevent anyone with a Firefox browser and Firebug to move away from the page, so you need some additional security as well. Why is the standard Domino behaviour not good enough? Or is it too ugly? Domino already keeps a "work"-copy of the document in memory, so another work-copy shouldn't be necessary.

You could also maintain a hidden field that gets a sequence number in the form. Each refresh the sequence number is updated by the Domino server. Whenever a document is posted with an outdated sequence number, you can give an appropriate message. Date/time should also be good, or just a random number, only to be set by the server of course.

Off to my room of reflection... *yawn*
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

Sjef BosmanGroupware ConsultantCommented:
You might even think of using @SetHTTPHeader and @GetHTTPHeader, if it is possible to stuff something in the header without the user tampering with it. Cookie and Set-Cookie maybe? That's what they're there for.


Each time the server sends a document to the browser, a new cookie should be generated; That way, the returned cookie should match the one sent away. If it doesn't, show a message and set SaveOptions to "0".
SaveOptions and @Command([FileSave] or @Command([FileCloseWindow]) are your friends.  With the WQS agent, perform your validation.  If it passes, then make sure saveoptions is set to "1" otherwise set SaveOptions to "0".  This will save the input the user has provided and allow the page to be re-submitted if necessary.  I generally will "hide" the button with the @commands with HTML, give it an id, and call the click of the button via javascript.  If the document is not valid according to the WQS, the document will return to the screen with the values the user entered, the document will not be saved (according to saveoptions) and the URL will have the added &SEQ=1.
CRAKAuthor Commented:
Thanks for your replies. A few things, like Bill's suggestion, had already come to mind. Can't remember exactly which hurdle appeared too high tough.
sparkymaster's suggestion seems pretty straight forward, but have you tried that in combination with the javascript to avoid going "back"? Did you use $$Return, or did you print a return url there?

We (we're working in a team on this application) will look into this on monday. We've spent our day on a few different, sometimes easier targets. The weekend will be a lot happier if it starts without a disapointment.
CRAKAuthor Commented:
Somehow we (my collegue is now handling this) keep finding flaws in the solutions.
We've found a way to stay in control though:
- According to our customer's wishes, we keep the anti-back js-line in place.
- Validation is done by the server (that's safer than a js solution and allows additional lookups). Validation results are returned through AJAX.
- If validation passes, we submit the document (js), which always triggers a WQS-agent.
- The WQS calls the very same validation routine again. It should never fail of course, unless someone is trying to trick our system. In that case, we can't be bothered returning that user to the original page: save is blocked and he/she will return to a warning page or the homepage.
Sjef BosmanGroupware ConsultantCommented:
So more or less the "standard Domino behaviour"? With a little help from AJAX, which serves only to help the users in preventing mistakes, but final validation is always handled by the server.

Interesting project!   ;-))
CRAKAuthor Commented:
As mentioned earlier: we decided to use AJAX to do the validation and report success or failures back to the client. Only if succesfull, submit (redoing the validation in case an uncontrolled submit is attempted) and leave further control to $$Return.
Only for a few document types (or actually sets of multiple documents) we have extended this approach with the creation of temporary documents (multiple users might be active in an update process). In this case validation (AJAX and save) would also check if the temp set in edit mode is still valid as successor (not valid if the original set was replaced by omeone elses save) and replace the active set with the temp ones.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.