I have a php form that runs through seven steps for the user to complete the
form. During each step validation runs before the user can see the next step
in the form, once completed there is a submit that send the info to a DB and
displays a "thank you" as a final step. Once the Thank you is displayed I
want to have a Yes and No choice for the user, if they select No I want the
session to destroy so other users can not see the info the previous user put
in the form by selecting the back button in IE. I don't want the destroy to
happen until the "No" button is selected. Any help as to how to approach
this problem?



Thanks,

Rob

On 4 Mar, 17:30, "rsvore" <rsv... [at] sbcglobal.net> wrote:
> I have a php form that runs through seven steps for the user to complete the
> form. During each step validation runs before the user can see the next step
> in the form, once completed there is a submit that send the info to a DB and
> displays a "thank you" as a final step. Once the Thank you is displayed I
> want to have a Yes and No choice for the user, if they select No I want the
> session to destroy so other users can not see the info the previous user put
> in the form by selecting the back button in IE. I don't want the destroy to
> happen until the "No" button is selected. Any help as to how to approach
> this problem?
>
> Thanks,
>
> Rob

It is a funny question really, since you obviously know how to code a
multipage form, I am wondering why you ask?!
If the form is already submitted at that point there doesnt seem to be
much point keeping the data around anyway. Just call session_destory()
however if you want the button to destory it like you suggest, why not
think of the Thank you as the last-but-one page of the form, although
the details have been added to the database, you can then add some
logic to destoy the session if a further input of type="button" is
submitted.
Or have the form post to an entirely new page, perhaps one which
destroys the session and then redirects them to something of interest.

"shimmyshack" <matt.farey [at] gmail.com> wrote in message
news:1173046817.151051.96630 [at] n33g2000cwc.googlegroups.com...
> On 4 Mar, 17:30, "rsvore" <rsv... [at] sbcglobal.net> wrote:
> > I have a php form that runs through seven steps for the user to complete
the
> > form. During each step validation runs before the user can see the next
step
> > in the form, once completed there is a submit that send the info to a DB
and
> > displays a "thank you" as a final step. Once the Thank you is displayed
I
> > want to have a Yes and No choice for the user, if they select No I want
the
> > session to destroy so other users can not see the info the previous user
put
> > in the form by selecting the back button in IE. I don't want the destroy
to
> > happen until the "No" button is selected. Any help as to how to approach
> > this problem?
> >
> > Thanks,
> >
> > Rob
>
> It is a funny question really, since you obviously know how to code a
> multipage form, I am wondering why you ask?!
> If the form is already submitted at that point there doesnt seem to be
> much point keeping the data around anyway. Just call session_destory()
> however if you want the button to destory it like you suggest, why not
> think of the Thank you as the last-but-one page of the form, although
> the details have been added to the database, you can then add some
> logic to destoy the session if a further input of type="button" is
> submitted.
> Or have the form post to an entirely new page, perhaps one which
> destroys the session and then redirects them to something of interest.
>

Currently the destroy is at the end of the script but if I'm on step one of
the form and go to step two and decide to go back to step 1 by using the
back button in IE it destroys session the step1 values and I have to
repopulate the fields. I have an include that pulls the DB population script
so I will try the destroy there.

rsvore wrote:

> Currently the destroy is at the end of the script but if I'm on step one of
> the form and go to step two and decide to go back to step 1 by using the
> back button in IE it destroys session the step1 values and I have to
> repopulate the fields. I have an include that pulls the DB population script
> so I will try the destroy there.

I would put in an extra page in the beginning, as you have it now, I guess, is:

page with link to form

first form page

second form page

...

yes or no page

kill session page


This has the funny thing that you recreate a session if you use the backwards
buttons and I guess thats what makes your session to be recreated. Do this
instead:

page with link to form

page creates session and then forward to next page with header()

first form page

second form page

...

yes or no page

kill session page


When you back from "first form page" you will come to "page with link to form"
without a new session is created. No new session is created when you go from
"second form page" to "first form page" as the session isn't created on that page.

Of course you can keep things like it is, but you have to check if there is a
session or not when you load "first form page", if none detected create a new
session, if session detected don't do anything.

I hope you did follow this quite late evening post.

--

//Aho

Thanks I'll work on it tomorrow.

R

"J.O. Aho" <user [at] example.net> wrote in message
news:55115vF233ernU1 [at] mid.individual.net...
> rsvore wrote:
>
> > Currently the destroy is at the end of the script but if I'm on step one
of
> > the form and go to step two and decide to go back to step 1 by using the
> > back button in IE it destroys session the step1 values and I have to
> > repopulate the fields. I have an include that pulls the DB population
script
> > so I will try the destroy there.
>
> I would put in an extra page in the beginning, as you have it now, I
guess, is:
>
> page with link to form
>
> first form page
>
> second form page
>
> ...
>
> yes or no page
>
> kill session page
>
>
> This has the funny thing that you recreate a session if you use the
backwards
> buttons and I guess thats what makes your session to be recreated. Do this
> instead:
>
> page with link to form
>
> page creates session and then forward to next page with header()
>
> first form page
>
> second form page
>
> ...
>
> yes or no page
>
> kill session page
>
>
> When you back from "first form page" you will come to "page with link to
form"
> without a new session is created. No new session is created when you go
from
> "second form page" to "first form page" as the session isn't created on
that page.
>
> Of course you can keep things like it is, but you have to check if there
is a
> session or not when you load "first form page", if none detected create a
new
> session, if session detected don't do anything.
>
> I hope you did follow this quite late evening post.
>
> --
>
> //Aho

On 4 Mar, 22:57, "J.O. Aho" <u... [at] example.net> wrote:
> rsvore wrote:
> > Currently the destroy is at the end of the script but if I'm on step one of
> > the form and go to step two and decide to go back to step 1 by using the
> > back button in IE it destroys session the step1 values and I have to
> > repopulate the fields. I have an include that pulls the DB population script
> > so I will try the destroy there.
>
> I would put in an extra page in the beginning, as you have it now, I guess, is:
>
> page with link to form
>
> first form page
>
> second form page
>
> ...
>
> yes or no page
>
> kill session page
>
> This has the funny thing that you recreate a session if you use the backwards
> buttons and I guess thats what makes your session to be recreated. Do this
> instead:
>
> page with link to form
>
> page creates session and then forward to next page with header()
>
> first form page
>
> second form page
>
> ...
>
> yes or no page
>
> kill session page
>
> When you back from "first form page" you will come to "page with link to form"
> without a new session is created. No new session is created when you go from
> "second form page" to "first form page" as the session isn't created on that page.
>
> Of course you can keep things like it is, but you have to check if there is a
> session or not when you load "first form page", if none detected create a new
> session, if session detected don't do anything.
>
> I hope you did follow this quite late evening post.
>
> --
>
> //Aho

can I just clarify, if there is already an exsisting session, why
doesn't the call to session_start() pick up on that fact and refuse to
create a new session.
php manual: "session_start() creates a session or resumes the current
one based on the current session id that's being passed via a request,
such as GET, POST, or a cookie"

It seems to me that was must be happening at the moment, for data to
be lost is that the variables are pushed to a completely new session
each time the form POSTs, this just seems to defeat the point of
sessions to me?

shimmyshack wrote:

> can I just clarify, if there is already an exsisting session, why
> doesn't the call to session_start() pick up on that fact and refuse to
> create a new session.

Yes, that is true, but we haven't seen the code, so the OP may be using
session_regenerate_id() when he creates the session or on some other way
messes things up.


> It seems to me that was must be happening at the moment, for data to
> be lost is that the variables are pushed to a completely new session
> each time the form POSTs, this just seems to defeat the point of
> sessions to me?

Thats a possibility too, but we don't know as long as we don't see the code.

--

//Aho

On 5 Mar, 11:16, "J.O. Aho" <u... [at] example.net> wrote:
> shimmyshack wrote:
> > can I just clarify, if there is already an exsisting session, why
> > doesn't the call to session_start() pick up on that fact and refuse to
> > create a new session.
>
> Yes, that is true, but we haven't seen the code, so the OP may be using
> session_regenerate_id() when he creates the session or on some other way
> messes things up.
>
> > It seems to me that was must be happening at the moment, for data to
> > be lost is that the variables are pushed to a completely new session
> > each time the form POSTs, this just seems to defeat the point of
> > sessions to me?
>
> Thats a possibility too, but we don't know as long as we don't see the code.
>
> --
>
> //Aho

thanks for that, i was assuming I was missing something, and had that
confused "huh" feeling for a moment!

> ...if they select No I want the
> session to destroy so other users can not see the info the previous user put
> in the form by selecting the back button in IE.

Saving form data between pages (unless you're script is doing it, in
which case you can just put in controls to stop it) is a browser
operation, nothing to do with the server. The best way for a user to
be relatively sure their form submissions (along with their session
data) is destroyed, is to close the browser. I would suggest simply
putting a note at the end of the form to close the browser if the user
is worried about others seeing what they entered.

On Mar 5, 8:38 pm, "dimo414" <dimo... [at] gmail.com> wrote:
> > ...if they select No I want the
> > session to destroy so other users can not see the info the previous user put
> > in the form by selecting the back button in IE.
>
> Saving form data between pages (unless you're script is doing it, in
> which case you can just put in controls to stop it) is a browser
> operation, nothing to do with the server. The best way for a user to
> be relatively sure their form submissions (along with their session
> data) is destroyed, is to close the browser. I would suggest simply
> putting a note at the end of the form to close the browser if the user
> is worried about others seeing what they entered.

dimo be careful what you suggest.
sessions is server based data storage, a token being sent to the
browser and then back to the server to link the browser by way of an
ID with the data from the form serialised and stored as session data
on the server against that ID.
Using a browser to "store" data is bad design. If you are posting a
multipage form why waste the servers time if you want to handle the
storage locally anyway.
Session detruction by closing the browser is again not reliable as it
depends on the implementation of the session server side as to whether
this even works. For instance well written sessions implement timeouts
which might last 5 minutes after the browser is closed, besides which
you might not have actually closed all the windows when you reopen the
browser. On top of this you are expecting a process to happen
automatically simply because the restarting of the browser means the
browser has "forgotten" the session ID, I havent checked this but I
would be willing to bet an infinitesimal amount of pretne dmoney that
firefox remembers session ID if it thinks it has crashed - as it does
remember form details - I stress I could be wrong, but relying on
browsers for funtionality you can code for youself seems wrong.
There is no reason why a session destroy script cannot be called
automatically. Even using a thankyou image

<img src="/great_big_smiley_disguised_as_session_destroy_image.php" />

which deleted the data would be easy and standard. I can't see the
reason why this isn't the way to go. Obviously though not an image but
a button which POST's (because it changes state of the app) to a
session_destroy script. This script could be the same script that you
use for an logout.