Javascript Security and History functions

[Nicki Pittman]

I have a web-based application that contains page with a form to allow
a user to edit their account information (i.e. address, phone, email,
etc.). This form is being pre-populated through XSLT from my
database. This form submits to a second form/page that uses XSLT to
compare the original values in my database to the parameters submitted
by the previous for to filter out which values have changed. This
second form will ask the user to confirm their changes, update my
database and then sends the user to a third page that will display a
message that the update was complete. My users are clicking the back
button from this message screen, to return to the confirmation form.
Upon doing so, the form does not display correctly due to the update
being completed.

I would like to use the history function to evaluate to force users to
be "redirected" to the message screen if they try to click the back
button from the message screen. (Essentially, I don't want the users
to be able to click the back button.) I know that I can NOT view the
history properties without the UniversalBrowserRead property enabled
via a signed script or SSL. My production environment will be SSL,
but I read that the user can deny this privilege. I have the ability
to include this as a "training issue" for my users, but I'm not sure
what browser versions, settings, etc. in IE and NS a user would need
to use. Has anyone had any experience with this?

Also, I read a few alternatives to using the history functions by
opening my forms in a new window or using cookies. Neither of these
are feasible for my application. Has anyone had any experience with a
different javascript function to avoid this issue?

Thanks in advance for your assistance!!!
Nicki S.
ka****@yahoo.com

[HikksNotAtHome]

In article <76**************************@posting.google.com >, ka****@yahoo.com
(Nicki Pittman) writes:

<snip>

This
second form will ask the user to confirm their changes, update my
database and then sends the user to a third page that will display a
message that the update was complete. My users are clicking the back
button from this message screen, to return to the confirmation form.
Upon doing so, the form does not display correctly due to the update
being completed.

How is the browser being sent to the "third page"? If you can rely on JS being
present, use location.replace() and it will replace the second page in the
history with the third. They click Back from the third page, they get the first
page.
--
Randy

[Nicki Pittman]

hi************@aol.com (HikksNotAtHome) wrote in message news:<20***************************@mb-m21.aol.com>...

In article <76**************************@posting.google.com >, ka****@yahoo.com
(Nicki Pittman) writes:

<snip>

This
second form will ask the user to confirm their changes, update my
database and then sends the user to a third page that will display a
message that the update was complete. My users are clicking the back
button from this message screen, to return to the confirmation form.
Upon doing so, the form does not display correctly due to the update
being completed.

How is the browser being sent to the "third page"? If you can rely on JS being
present, use location.replace() and it will replace the second page in the
history with the third. They click Back from the third page, they get the first
page.

Thanks for the recommendation Randy! The location.replace() sounds
like a good option since no history entry is made. But I still have a
question....

My users are passed from the first screen to the second screen AND the
second screen to the third screen by submitting forms (post method to
update my database). My urls are dynamic based on parameters passed
through the application, session ids, database processes that validate
any changesn with other systems, and the xslt stylesheet names. Since
I am not linking to a "static" url in my application, would the
location.replace() function as it needed?

I apologize for my Friday Stupidity Leak...I've been stumped on this
issue for a while now.

Thanks again for your help!

Nicki
ka****@yahoo.com