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".
Courses: Start Training Online With Pros, Today

Brush up on the basics or master the advanced techniques required to earn essential industry certifications, with Courses. Enroll in a course and start learning today. Training topics range from Android App Dev to the Xen Virtualization Platform.


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

Announcing the Most Valuable Experts of 2016

MVEs are more concerned with the satisfaction of those they help than with the considerable points they can earn. They are the types of people you feel privileged to call colleagues. Join us in honoring this amazing group of Experts.

Question has a verified solution.

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

  In today’s Arena we can’t imagine our lives without Internet as we are highly used to of it. If we consider our life style just for only 2 min we found that face to face communication is swapped by e-communication.  Every Where from Works place to…
Lack of Storage capacity is a common problem that exists in every field of life. Here we are taking the case of Lotus Notes Emails, as we all know that we are totally depend on e-communication i.e. Emails. This article is fully dedicated to resolvin…
This Micro Tutorial hows how you can integrate  Mac OSX to a Windows Active Directory Domain. Apple has made it easy to allow users to bind their macs to a windows domain with relative ease. The following video show how to bind OSX Mavericks to …
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

813 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

19 Experts available now in Live!

Get 1:1 Help Now