Session Variables holds Order Number - pressing BACK KEY is a problem 1

[jjbrad]

We have an entire Order Entry system written in ASP - whatever version that goes with Windows 2000 Server (not ASP.NET).

In global.asa, we have:


sub Session_OnStart
Session("intOrderNo")=0
end sub


As it implies, this is used just about everywhere to tell the computer what row(s) to update or retrieve in the database.

Since a "Session Variable" spans windows and forms, if follows that Session Variables part of the Session State does not regress to its prior values when the back key is pressed.

This has, in the past, caused all sorts of security and corruption issues.

Our Order Desk has long since been educated to not use the BACK KEY, but we are allowing more and more customers to enter their own orders over the internet, and I'm a little embarassed each time I tell one "don't use the back key".

I don't know enough ASP to think of the best solution.

I believe the SESSION stuff is kept on the server, and BACK is done on the client. I'm unclear if BACK key would always entail a round trip back to the server, or if there would be some way to force that.

Here's some things I've considered:

1. Disable BACK key. Don't know of any way to do this except removing the whole menu bar. And even then, some mouses are equipped with back buttons, and there's keyboard shortcuts, etc. Is there a way to simply disable BACK?

2. Find some way on every page to sense if "back key was pressed". Create an include file for every .asp file that manages the problem. Probably a Javascript alert() that educates that user - seems hoaky.

Before I go too far down the "unusual solution" road, I just thought I would solicit some sage advice.

Suggestions?

 

[mwolf00]

Disabling the back key is a non-starter since they can use the backspace on their keyboard to go back also.

Can you trace their session? I mean when they jump from one page to another make sure you write it to a DB including their "intOrderNo" - then when a page loads, you can see if they've been there before. Your can keep the table small by removing data when the session ends. Make sure to use response.expires = 0 when doing this

My biggest question is why is that number so important? What does it matter if they've gone back to order more? Can you explain a little more?

Programming today is a race between software engineers striving to build better and bigger idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. - Rick Cook

Tsunami Relief Inform​

 

[Sheco]

I'm unclear if BACK key would always entail a round trip back to the server, or if there would be some way to force that.

Going BACK the page usually just comes out of the browser cache.

Setting the page to expire may help more with some users than other because results vary depending on the users browser configuration... if a customer has downloaded one of those "Internet Accelerator" programs then forget it.

Web applications should be designed to be as "stateless" as possible... because users can do things, including creating shortcuts, that they just can't do in traditional desktop applications.

Even if you get a good psuedo-state going with session variables... well now you have to worry about session timeouts... someone WILL leave the page open when they go to lunch or a meeting and they WILL attempt to continue right where they left off... except now their session is expired... so you need to account for that as well.

 

[jjbrad]

Thanks for responding.

This is a comprehensive application. It has several screens that utilize Order Number. For example, if they are looking at their Accounts Receivable screen, it shows general information but in one section focuses on all payments for one Order Number (invoice actually). Then they click on "View Order" and it shows them the order header and a summary of all line items. Then, lets say its the Sales Manager doing the viewing, he clicks on Special Pricing to give this particular order a discount. But when in the Special Discount screen, he decides to go into Edit Order screen to add a comment or make a notation for the factory to "rush this order". And so on.

This Session("intOrderNo"), if not zero, always indicates what order to display.

Also, oweing to the nature of ASP, the programs are recursive and don't "remember" anything that hasn't been passed by a FORM submit or by a QueryString. So early on, a shortcut was taken maintain a few Session Variables that "always contain the value of what we're working on".

I've attempted to nail down every place where a wrong Session("intOrderNo") could cause an incorrect update or insecure situation (such as showing one customer another customer's order). But, every once in a while something crops up that I suspect was caused by this.

So, I would like a way to disable BACK key.

Question: How does the back key work? Is there a way to load a page so that BACK KEY will never work (such as turning off caching)?

Also: With several hundred orders a day, and several thousand line items, this only becomes a problem about once every 2 months. Its still very important but creating a trace to capture the event, then actually benifiting from that capture, will be difficult at best.

Therefore: I would like to explore some magic pill, like caching or disabling something, to solve the issue before implementing a programming intensive system wide solution such as maintaining database updates which itself could be prone to programmer error.

Much thanks for your attention!

 

[Sheco]

The problem with BACK is that it is a feature of the browser... not the server.

What works in one browser version won't necessarily work in the next... and then there are those folks using Mozilla...

What I'm about to suggest is a hack... it won't necessarily work for every browser and it won't work at all if the user has a pop-up blocker but...

...if you use your front page to launch the remainder of the site in a pop-up window. Define your pop-up to have no control buttons or menu ... like you see for pop-up ads.

...Next trap the right-click event to prevent the context menu from coming up... if you do all this then it will be more difficult for the user to go back... at least with most current browsers that support such things.

 

[jjbrad]

Our user base is only internal intranet users plus about 2,000 customers. They have to bend to our demands if they want internet convenience. After all I'm just one programmer / band-wagon to support it all. The form they sign to get an account states that only IE5.0 or greater is supported and we block others at sign-on time. So, Netscape, Mosiac, etc. are not an issue at this juncture. Disallowing pop-up blockers is probably streaching it though, since we've installed them here already.

That said; I'm wondering about other down-sides. IE: Would this cause problems for our Crystal Reports plug-ins, would future pop-up blockers suddenly disable our site, etc.

I'm wondering if there's a way to do a Javascript whenever a new form is loaded that senses if BACK key was pressed, and if so, simply set intOrderNo to zero and do an alert telling them not to use BACK key in our application. Then possibly re-direct back to whatever screen they were on before after they press OK - or log them off.

Do you think something like that would be possible?

 

[hithere]

jjbrad,
awhile back (no pun intended), we found ourselves wanting to disable the back and/or the X(close window) buttons. I remember that I looked all over the 'net and googled a lot trying to find code to do it to no avail. I vaguely remember an article that discussed that it had been considered being made available at one time but it was rejected as a bad idea by the browser folks (same with eliminating the X). maybe I'm misremembering about the "back" (I'm sure on the X) but...I wouldn't be surprised at all to discover that you have no option available to you for disabling the "back".

you mention that it's a "comprehensive application". sounds big. lots of pages, lots of code I presume? so we can figure that moving away from session variables and doing db calls for order #('s) instead is not a viable option? are cookies currently being used at all so that you could transistion to those instead of session variables?

"Where's the Ka-Boom? There's supposed to be an Earth-shattering Ka-Boom!"
Marvin the Martian

 

[trollacious]

If you have the page that processes the order redirect to the final page that displays the confirmation, then the history link to the processing page itself doesn't exist, and anyone hitting the Back button will return to the page prior to the processing one. This might take care of the problem you're having, or give you some ideas on the subject.

Lee

 

[hithere]

here's article about the disable back thing with some ideas around it etc.

http://www.dotnet247.com/247reference/a.aspx?u=http://www.4guysfromrolla.com/webtech/111500-1.shtml

hth

"Where's the Ka-Boom? There's supposed to be an Earth-shattering Ka-Boom!"
Marvin the Martian

 

[jjbrad]

to hithere:
Thank you for the reference - which itself contains other relevant references.

Yes, I believe there's a few pages. Mainly, more so than the number of pages, the ones used extensively and maticulously have been heavily modified and tweaked and integrated and have pretty much spawned little lives of their own.

I'm in the middle of about 6 projects now (aren't we all) - 1 being to write a rudementary inventory system (wrapping that up tonight) and another being to make that system robust (figure 2-3 months). Its more database stuff than ASP, but ASP is the window dressing. This caching problem is number 7 and number 8, but I'm chipping away at it when I can so I don't think I can try your suggestions for a few days.


to: trollacious

Thank you so much for your comment. However I'm not good enough with ASP to understand the ramification you imply.

"redirect to the final page that displays the confirmation, then the history link to the processing page itself doesn't exist"

Does that mean that a redirect wipes out the page history?

We don't have any one page these updates are done from, and there are many places within these pages that do updates and queries, but if what you imply is true, it does offer food for thought. One more step.

Thanks!

 

[trollacious]

When you submit a page, you use one page to process the information. Then, after the information is processed, you redirect to a page that displays whatever message you wish that everything is done, or that there were errors so the information wasn't processed. By using Response.Redirect to the message page(s), the history for the page that did the actual processing is missing, so the back button will take them to the page BEFORE that, the one where they submitted from. You can clear Session variables, whatever you want, on the processing page, and the functions that perform those operations and those can't be accessed again unless the original form is submitted again.

The only page history that is "wiped out" is the page redirected from, which would be the page with the functions to process the data submitted. That page is never sent to the client computer, but redirected on the server after the processing is done. Since it never made it to the client computer, it cannot exist in the client computer's history to go back to when the Back button is clicked.

Does this make more sense? This is the method I use to process data to insure that clicking the Back button, OR the Refresh button, won't resubmit the information.

Lee