WebQuerySave magic

Posted on 2009-05-07
Last Modified: 2013-12-18
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?
Question by:CRAK
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 3
  • 3
  • 2
  • +1
LVL 22

Assisted Solution

Bill-Hanson earned 150 total points
ID: 24328923
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'.
LVL 46

Assisted Solution

by:Sjef Bosman
Sjef Bosman earned 150 total points
ID: 24331823
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*
LVL 46

Expert Comment

by:Sjef Bosman
ID: 24333948
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".
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!


Expert Comment

ID: 24338304
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.
LVL 13

Author Comment

ID: 24338510
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.

Accepted Solution

sparkymaster earned 200 total points
ID: 24338562
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).
LVL 13

Author Comment

ID: 24392951
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.
LVL 46

Expert Comment

by:Sjef Bosman
ID: 24393337
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!   ;-))
LVL 13

Author Closing Comment

ID: 31579138
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.

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

This is an old article, please see an updated version of this article, located here:
Article by: Rob
Notes 8.5 Archiving Steps and Tips This article covers setting up a Notes archive, and helps understand some of the menu choices making setting up and maintaining a Notes archive file easier.
A short tutorial showing how to set up an email signature in Outlook on the Web (previously known as OWA). For free email signatures designs, visit If you want to manage em…
In an interesting question ( here at Experts Exchange, a member asked how to split a single image into multiple images. The primary usage for this is to place many photographs on a flatbed scanner…

752 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question