Beefy Boxes and Bandwidth Generously Provided by pair Networks
go ahead... be a heretic
 
PerlMonks  

How do you do sessions in Web Sites

by digiryde (Pilgrim)
on Sep 27, 2005 at 18:46 UTC ( [id://495501]=perlquestion: print w/replies, xml ) Need Help??

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

Simply, I would like a discussion/feedback from any and all on how to do sessions for websites and why to do them that way.

I am preparing to redo the base code for many of the websites I manage. I have always done session management in a very simplistic and limited manner, and now I am looking to others to see what else I could and should do.

Currently, I use several bits of information to pull together an ID. Then, I encrypt that ID and put it in a cookie on the remote browser. I link that ID in a table to a user, a site and/or a state.

This has problems. The URL can not be copied and pasted to send people to the same web *page*. A user who does not/can not allow cookies can not use the site (this is a a major reason to change this). Update - The URL can hold the information for the state in it. Some of that we do just in paths and pages/scripts. Information about state that is server side and linked by a session can not be copied and pasted in the url unless the url contains the session id, so a cookie can not do that.

Recently, I added a kludge to my old method to allow using the URL to hold a session state when cookies are not available. I feel I need to revisit this with a better more permanent solution that can address more end user needs and wants.

Please discuss what you do why you do it, why you think it is better, what the drawbacks of other methods are and how you do it. (or any one of those ;-)

After a while, I will summarize the thread for the site.

Replies are listed 'Best First'.
Re: How do you do sessions in Web Sites
by BUU (Prior) on Sep 27, 2005 at 20:05 UTC
    I only know of two real ways to do this.

    1) Embedding the session id in the URL:

    You can implement this one in two ways, or some combination thereof. The first way is manual, where you assign a template variable to contain the id and manually include it in every URL. This generally sucks from a designer's perspective. The second way is have something that automatically adds it; depending on the languages and technologies you are using, it's usually fairly easy to do, but some things can prevent it.

    This technique has several flaws, the most major of which is security. People, in general, don't think of URLs as something to be security concious of and will probably freely share them. If their session id is stored in the url and someone else uses it, they'll probably have access to what ever sensitive data was stored in the session. You can try to prevent this by adding checks based on originating ips of the sessions but that runs the risk of screwing, or at least annoying, people behind a rotating proxy, for example, AOL.

    2) The second solution is to just use cookies. They're simple, incredibly easy to use, and already handle all of the above security concerns. The only down side is that occasionally they won't work, but really, the percentage of people who have actually disabled cookies is so small it's probably not worrying about. In general, if they want to use your service and cannot do it with out cookies, they'll turn cookies on.

    To summarize, if you just want to track each user on your site much like amazon does, you should probably use session ids in the url. It doesn't need to be secure but does need to work for most everyone. If you have secure data you're protecting via the session id, you probably want cookies, much like amazon does when you actually log in to your account.
      3) Put them in a hidden field, and only allow communcication to the server through POST (submitting the form).

      Just for completeness :)

        Just remember that if you use POST for every page, depending on their browser (mis)configuration or browser (mis)behaviour, you will basically break the browser "Back" button.

        It's going to ask the user every time s/he hits "back" with that annoying message, "do you want to re-submit this form?", and the users will probably be confused and not know what to do. :(

Re: How do you do sessions in Web Sites
by jkva (Chaplain) on Sep 27, 2005 at 18:51 UTC
    Just a thought,

       Perhaps, together with, or instead of cookie use, you could try something like

    http://site.com/script.pl?sessid=encrypted_session_id or
    http://site.com/encrypted_session_id in case of pathinfo use.

       This is of course linked to the session table on the server side.

    I bet, that with a few snazzy math tricks, you can encode the current site state in that id, so you can use it for bookmarks.

    -- Detonite
Re: How do you do sessions in Web Sites
by perrin (Chancellor) on Sep 27, 2005 at 19:09 UTC

      The former is marked as beta code and the latter fails to build (im trying to figure out why right now). Im just curious why you recommend these modules in particular? For someone not too familiar with the issues its hard to do a feature comparison.

      ---
      $world=~s/war/peace/g

        Most of CPAN is marked as beta code, but this is from a reliable author and has been out for years. Apache::SessionManager also has a helpful author who shows up on the mod_perl list and answers questions.

        Apache::AuthCookieURL is a good example of a module that does tracking without cookies. Apache::SessionManager solves most of the issues people normally have with using sessions, and is good for beginners who don't know what is already there and what they need to supply.

Re: How do you do sessions in Web Sites
by cfreak (Chaplain) on Sep 28, 2005 at 00:31 UTC

    Encrypting the strings yields long URLs or large cookie data. I usually use a one way hash algorithm such as MD5 on the ID (of course that's getting somewhat dangerous now due to the apparent hackability of MD5, SHA-256 might be a better choice) and store that in the cookie, or the URL. I store a copy of that in the database with the row of information I need for the user.

    For extra security you can change the session string each time they hit the site. I would do this especially if you're using URLs since that way the session string is likely to have changed if your user shares the URL with someone and you can generate a new session or ask the new connecting user to login or whatever.

    I can't say I've used the session modules that people so often talk about. I really don't like extra temp files that many of them create. I know some of them have options for using the database, but I typically have to make a call to the database anyway, why make a separate one?

    I'm not going to say my method is better/worse than anyone else's. It works for me!

Re: How do you do sessions in Web Sites
by cowboy (Friar) on Sep 27, 2005 at 20:11 UTC
    Currently I am working with Mason, and I store the session identifier in a cookie if possible, if not, in the url via a mason filter.
    The session data is stored in a database table as a blob using Storable. For the users who use cookies, the page is bookmarkable/pasteable. For the others, well, it's kinda ugly.
Re: How do you do sessions in Web Sites
by zby (Vicar) on Sep 28, 2005 at 14:05 UTC
    Having state data in the url might be usefull - for sending the address to an exact state of the server. But user id in the address does not seem like a good idea to me - the receiver of a sent bookmark would login using the senders user id.

    I think for authentication you can use only cookies or http authentication, no paths (urls).

      Wow-- looks like you kinda reinvented the wheel-- CGI::Session should sessions-- and you can include the session id in the URL.
        I don't understand where I am reinventing something. If the session is in the url and a session is owned by someone then if someone else uses that url he will be logged in as the original user. This is confusing from many points of view. So ideally you should split the authentication part of the session from the state part and code in the url only the state part.

        To put it in other words there is a public and private part of the session and since urls are mostly treated as public you should not use urls for the private part of the session. This is a general remark. If you want to concentrate on CGI::Session then we can analyze if it fits to this kind of usage.

Re: How do you do sessions in Web Sites
by Delusional (Beadle) on Sep 29, 2005 at 12:20 UTC
    Man or may not be usefull:
    $time = time * (int(rand 200) + 1); $session = substr($time, 4, 4) . substr($time, 5, 4); $session =~ s/(\d\d)/substr("ABACADAEAFAGAHAIAJAKALAMANAOAPAQARASATAVA +WAXAYAZCACBCDCECFCGCHCICJCKCLCMCNCOCPCQCRCSCTCVCWCXCYCZDADBDCDEDFDGDH +DIDJDKDLDMDNDODPDQDRDSDTDVDWDXDYDZYAYBYCYDYEYFYGYHYIYJYKYLYMYNYOYPYQY +RYSYTYVYWYXYZQAQBQCQDQEQFQGQHQIQJQKQLQMQNQOQPQRQSQTQVQWQXQYQZ",$1, 2) +/eg; substr($session, int(rand 5) + 1, 1) = int(rand 9);

    Essentually, take the current time (in EPOC) convert that to random letters, and save it in $session. You can then push that as a cookie or form element, as well as save it to the database table. This would handle a session, and should never ever be the same for any two users. As far as putting URI's or other info into the $session handler, I'd go with either adding more cookie entries or form field enteries. Keep in mind, users are nasty. They will do anything to keep there information private. So, adding a check for the cookie before processing is the best way to go, if the check fails and your database shows an entry saying that the user is logged in, then check the form fields, if they block both then there probibily blocking javascript, thus chances are, there not going to effectivily be able to use any web site that requires session id's or form information.

    The coding is far from perfect and far from a solution. Just adds an alternative. You could, alternativily, catch the calling IP from the users broswer informaition (that usually is available even when everything else isn't), and use that with your database to handle the sessions. Meaning, if the user comes from the IP 127.0.0.1, and cookies are not present, javascript doesn't work, and form fields arn't comming through, save the IP to the database, and refer to the IP from the browser and database to confirm sessions. No two IP's should ever be the same. Id also send a message to the user, in the html document, telling them that cookies should be allowed for the site in order to effectivily use it. If they don't what to allow cookies, then why are they even visiting the site and using the functions....
Re: How do you do sessions in Web Sites
by pajout (Curate) on Oct 17, 2005 at 12:00 UTC
    I use following model:
    1/ When new session created (for every user, including anonymous), session identificator is generated as random string, beginning with letter, for instance g4Kj90hUl.
    2/ Depending on application requirement, that sess_id is included as hidden field in every application page, or/and the cookie with sess_id is sent. The advantage of hidden field is the possibility of two opened browser windows with different login, the advantage of cookie is the possibility of walking out of application url and back without lose of authentication. I think that GET or POST is another story.
    3/ The aditional session informations, including expire rules, are stored in SQL (or Berkeley :) database under sess_id.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://495501]
Front-paged by Arunbear
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2024-03-28 12:14 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found