Greg Klinedinst (
[email protected]) wrote:
: On Wed, 03 Mar 2004 21:07:58 +0100, Vetle Roeim <
[email protected]>
: wrote:
: > If you put the session id in the URL, your system may be vulnerable
: > to session hijacking.
: >
: > If the user goes to a page in your system (with the session id in
: > the URL) and clicks a link to an external site, the session id will
: > appear in the referer-header that is sent to the external site.
: >
: > Sverre H. Husebys "Innocent Code" covers this, and much more.
: > <URL:
http://innocentcode.thathost.com/>
: The user can find out their own session ID in all cases, since in all
: cases it is data they(the client) are sending to your server. The only
: real difference is that with the URL/hidden vars way you don't need to
: worry about the client rejecting cookies. Also the URL way(GET)
: probably isn't ideal b/c the URL has a maximum length, so hidden
: vars(POST) are best IMHO. You just have to make sure that they cannot
: guess how you created the session ID, and make sure you expire session
: IDs in your DB.
Cookies are handled by the browser, so they may be easier to code. You
set them just once, and then read them as necessary, no need to ever
accomodate them in your pages. In particular your web site can use static
pages when ever it is convenient, and the context is not lost.
Caching can mean that old values are passed around, whereas the cookie is
always up to date.
A cookie can be changed independently of the pages (which can be good or
bad).
Personally, I have set up pages that used nothing but hidden fields, but I
don't do it anymore. I have found that a cookie is just too much easier
to use (unless you pay me well - then I would of course) mostly because
you only ever use them when you need them, whereas a hidden field must
always be passed around somehow, which limits the techniques available for
generating pages, links, and etc.
Someone mentioned the problem of the referrer header passing information
to unrelated sites, and therefore links should not contain session ids. I
just thought I would reiterate that, because if you know someones session
id it can be trivial to play in their session.
As for user's turning cookies off, this is no different than (for example)
selling an item with a picture and trying to accomodate a person with a
text browser - at some point you just have to say "sorry", you need a
certain base level to access all the features of this site. Same with
Javascript. I understand the reluctance of some people to turn it on, but
at some point the user needs to decide if they want to interact with you,
kind of like deciding whether they will bite the bullet and key in their
credit card number - at some point they must do what _you_ want if they
want to interact with your system.
--
Web Work Wanted, Perl Projects Programmed, Database Development Done.
I'm looking for telecommute projects. (Paying that is, various
arrangements possible.)