[FX.php List] [OFF] Theory of managing sessions

[Jonathan Schwartz]

Troy,

Thanks.  That _is_ an interesting way to manage a multipage process, 
and I think that I might try a flavor of that in the future.  I had 
already been thinking about how to make my current "linear" process a 
more Hub and Wheel process....an idea that had been planted by 
someone else on this list a  long while back.

However, for this project, I just need to fix this loophole which 
boils down to how to destroy a session using the "session-in-URL" 
method.

Thanks

J


At 6:47 AM -0800 11/19/07, Troy Meyers wrote:
>Jonathan,
>
>I don't know if it would work for you, but I store "what step the 
>user is in" data either in the session or in FileMaker (coupled with 
>a record owned by the user) and use the _same_ URL for each step in 
>an interview process. That way, if the user resubmits an old form it 
>is recognized on the server end that the user should be in a 
>different step, and that step is displayed, including possibly a 
>page that asks if a new interview should be started, if the old one 
>had ended. Doing it this way, though, you need to have backward 
>navigation for the user coded in the page so they can go back an 
>change something in an earlier step, if that's allowable.
>
>I can't see why this wouldn't work using either the 
>session-in-cookie or the -in-URL method. If the session had been 
>destroyed, the PHP should be able to recognize that and start at the 
>appropriate spot.
>
>Make any sense?
>
>-Troy
>
>
>>  Hi Folks.
>>
>>  Sorry for the slightly off topic post.  I'm having trouble getting
>>  this straight...
>>
>>  The question is how to properly use sessions to allow and limit  access
>>  to a solution.  My  current dilemma: how to restrict folks  from
>>  revisiting pages of a mulltipage solution after they have  completed the
>>  process...when using SID.
>>
>>  In my current solution, I am using SID to make sure that I don't have
>>  cookie problems. When cookies are not available from the user's
>>  browser, the PHPSESSID appears in the URL.  The last step of the
>>  process is a page that runs session_destroy.  Yet, I can use the
>>  browser history (Safari) and re-load pages from the solution. They
>>  display with data from the session...and the PHPSESSID still appears  in
>>  the URL.
>>
>>  I thought that session_destroy was the way go to wipe the session.  For
>>  reference, This doesn't happen when browser cookies are turned  "On" and
>>  the system doesn't use SID.  Also for reference, I am using  simple
>>  check at the top of each page to check whether a session is  "on" and
>>  dump to a "ended" page if the test fails..
>>
>>  if($_SESSION['SessionInd'] != "On" ) {
>>
>>    header('Location:ended.php');
>>
>>  }
>>
>>  The SessionInd is set when the user logs in.  I probably need to beef
>>  this up.
>>
>>  What am I missing withe SID method?
>>
>>  Thx
>>
>>  Jonathan
>
>_______________________________________________
>FX.php_List mailing list
>FX.php_List at mail.iviking.org
>http://www.iviking.org/mailman/listinfo/fx.php_list


-- 
Jonathan Schwartz
Exit 445 Group
jonathan at exit445.com
http://www.exit445.com
415-381-1852