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
  • 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".

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.
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

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

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

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

Suggested Solutions

Title # Comments Views Activity
Domino not switching to TLS 1.0 4 775
Lotus Notes transfer mail box problem 6 95
See used databases in Domino 8 100
Migration Lotus to Exchange 2016 4 151
I thought it will be a good idea to make a post as it will help in case someone else faces these issues. I trust this gives an idea how each entry in Notes.ini can mean a lot for the Domino Server to be functioning properly. This article discusses t…
For beginners of Lotus Notes user this is important to know about the types of files and their location supported by IBM Notes. Mostly users are unaware about how many file types are created and what their usages are. This Article is fully dedicated…
Along with being a a promotional video for my three-day Annielytics Dashboard Seminor, this Micro Tutorial is an intro to Google Analytics API data.
With the power of JIRA, there's an unlimited number of ways you can customize it, use it and benefit from it. With that in mind, there's bound to be things that I wasn't able to cover in this course. With this summary we'll look at some places to go…

863 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

Need Help in Real-Time?

Connect with top rated Experts

26 Experts available now in Live!

Get 1:1 Help Now