hotshot has asked for the wisdom of the Perl Monks concerning the following question:

Another one!

We have a web site, that requires login. on login a session id is created and while we get it on the server side (we send it back to the server each time a link is pressed), the session is alive.
The web site is built in frameset and perl is runing on the server side.
The problem is that when the user presses the browsers Refresh button, I (on the CGI) don't get the session id (actually I don't get any parameter), and therfore I throw the user back to the login page.
Is there a way to solve this in that the user won't be thrown out (and will only refresh the page he is currently in)?

Thanks

Hotshot

Replies are listed 'Best First'.
Re: Refresh problem
by tachyon (Chancellor) on Mar 18, 2002 at 10:38 UTC

    If you are constrained thusly why not store the session id in the url rather than as a hidden field? If you are using POST for your data this should not involve a major change. Then refresh should work.

    http://yoursite.com/session.cgi?id=MD5hash # in the cgi if ( $ENV{'$QUERY_STRING'} =~ m/id=(.+)/ ) { my $session_id = $1; valid_id($session_id) ? continue_session($session_id) : new_sessi +on(); } else { new_session(); }

    cheers

    tachyon

    s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Re: Refresh problem
by vagnerr (Prior) on Mar 18, 2002 at 09:54 UTC
    When the user hits refresh the browser is refreshing the entire frameset. IE if you have the frameset url as http://www.mydomain.com/ which causes a frame to load with the url http://www.mydomain.com/sessionid=123987129837 then when they hit refresh the broswer will load the first one causing an entire new session to be created.
    Your best bet is probably to try and backup your URL based session ID with a cookie. This won't be perfect as anyone with cookies turned off will of course still get kicked out but it will catch most users.

    ---If it doesn't fit use a bigger hammer
Re: Refresh problem
by Ryszard (Priest) on Mar 18, 2002 at 10:51 UTC
    I guess there are many reasons why one wouldnt use cookies, however if they wont let you because of "grave security concerns" perhaps you could let them know it is perfectly acceptable in the wider session management community to use cookies to store session id for the purpose of keeping state.

    If however you are not allowed to use cookies because your application will be used on WAP devices, then I'm afraid its sess_id's in the url for you.. :-)

Re: Refresh problem
by dws (Chancellor) on Mar 18, 2002 at 08:47 UTC
    on login a session id is created and while we get it on the server side (we send it back to the server each time a link is pressed), the session is alive.

    How are you sending the session id back? Hidden form field? Cookie?

      I use hidden form field, they don't want me to use cookies.

      Hotshot
        I use hidden form field, they don't want me to use cookies.

        You're hosed if you expect forms to repost on refresh. You either need to embed the session ID in the URL, or convince "them" to let you use cookies.

        If you're sure than none of your clients are sitting behind any sort of network address translation (NAT), then you might be able to keep track of session on the server side, by associating them with the client's IP address.