http://qs1969.pair.com?node_id=657256

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

Hi, I have another question about the session-id, what if the visitors are the first-time to visit your website? and some of their browers might not support cookie? how do you design the session-ids from the server-side? By design, I mean how can we know if or not the client-sides support cookie so that we don't re-send cookie(with new seesion-id) to those who disable cookies from the other side?? Many thanks..

Lihao(XC)

Replies are listed 'Best First'.
Re: Another question about session-id
by McDarren (Abbot) on Dec 16, 2007 at 06:40 UTC
    Not a direct answer to your question, but it may be worthwhile taking a look at Basic Cookie Management, an article on this subject by merlyn

    Cheers,
    Darren

Re: Another question about session-id
by zer (Deacon) on Dec 16, 2007 at 08:45 UTC
    one method would be to write a script that reads the cookie after you write it. Set the session-id in the header, pass the "Location:" header to another script, attempt to read the cookie. If you can read it great, otherwise tell the user that it isnt enabled.
Re: Another question about session-id
by pfaut (Priest) on Dec 16, 2007 at 14:53 UTC

    Merlyn's article in the first reply was very useful to me. In cases where the browser is not accepting the cookie, you could embed the session ID in the URI and retrieve it from PATH_INFO. I have used this scheme on a few sites. This isn't a good idea for secure sites, however, since the session ID is displayed in plain view in the browser's address bar and could be easily hijacked by a passerby.

    90% of every Perl application is already written.
    dragonchild

      since the session ID is displayed in plain view in the browser's address bar and could be easily hijacked by a passerby

      While I applaud your attention to security, I think you're passing the security boundary and into paranoia. If someone passing by can easily remember a sessionid then either your session ids are way too small or the person is wasting their time and should be in a casino somewhere counting cards.

      But ... if you're still really worried, you could combine the true session id with something else, a nonce, that isn't seen by the passerby. Some people use the ip address of the incoming request but you really need to know your clients to do that (there could easily be lot's of clients coming from the same nat gateway). Or you could create a nonce on your own and insert it as a hidden field. The problem there ... every request would need to be a POST.

      Personally, I've given up on the people who do not accept cookies. The only thing I try to do is minimize the number of cookies I create (I'm almost down to one!). It's a trade-off.

      -derby
        While I agree that concern with passers-by memorizing or writing down a session ID in the URL is excessive (especially since most sites' session IDs are tacked onto the end of a URL that's large enough that it isn't all displayed on the screen anyhow), putting it in the URL also means that it will be recorded in the server's access log as well as any intermediate proxy logs. Those logs may be readable by untrusted third parties, creating a possible threat. (I wouldn't go so far as to call it a likely threat, but it's nowhere near as remote a possibility as someone looking over your shoulder and getting it off the screen.)

        In any case, like you, I've pretty well taken the position that cookies are a fact of life if you want to log in to a site, so just enable them (but disable third-party cookies if your browser has that option) and get on with it.

      Amazon does both cookies and session ids in the path (and every URI on the page). As long as you are expiring these at the end of a "visit" and mixing in things like IP and user agent on the server side, this can work fine. Plus, with their model, they require a secure sign-in every time you perform account altering actions ("no" for putting something in the cart, "yes" for paying for something or changing an address).

      If you do both, you can basically ignore whether or not the client supports cookies. Then again, cookies are so basic to web functionality today that I don't think the dual model is really justified compared to the extra overhead (URI rewriting) and complexity it adds.

      Hi, Thanks all for the useful link and suggestions :-)

      I think Mr. Schwartz's method is pretty much helpful(basically I think it takes the same approach as shown in Gavin's above post). So every first-time visit to my website has to take a test to check if the browser responses with a proper cookie information. Sounds a perfect solution and I don't need to issue any redundent information on the URL after then.

      the only downside I can feel is that for the first time visitors, this approach means an extra 302 redirection when they first see my webpage, and if the visitor is a robot which usually doesnt accept cookies, this approach might double(not double exactly since redirect happens at early stage) the net-flow from those robots:--((( but it should not be a big problem by caching from both client and server side.... not sure if there is any other side-effects though?

      very nice learning... thanks :- )

      Regards,

      lihao(XC)

Re: Another question about session-id
by Gavin (Archbishop) on Dec 16, 2007 at 13:45 UTC
    Could this not be modified to suit:

    #!/usr/bin/perl -w use strict; if ($ENV{'QUERY_STRING'} ne 'TESTING') { print "HTTP/1.0 302 Moved Temporarily\n"; print "Set-Cookie: Cookie=Test\n"; print "Location: $ENV{'SCRIPT_NAME'}?TESTING\n\n"; } else { if ($ENV{'HTTP_COOKIE'} =~ /Cookie=Test/) { print("Content-type: text/html\n\n"); print("<HTML>"); print("<HEAD><TITLE>$ENV{'HTTP_USER_AGENT'} supports Cookies</ +TITLE></HEAD>"); print("<BODY>"); print("Your browser, $ENV{'HTTP_USER_AGENT'}, supports the Net +scape HTTP "); print("Cookie Specification."); print("</BODY></HTML>"); } else { print("Content-type: text/html\n\n"); print("<HTML>"); print("<HEAD><TITLE>$ENV{'HTTP_USER_AGENT'} doesn't support Co +okies</TITLE></HEAD>"); print("<BODY>"); print("Your browser, $ENV{'HTTP_USER_AGENT'}, doesn't appear t +o support cookies."); print("Cookie Specification."); print("</BODY></HTML>"); } }

    From What is CGI.