Re: my previous post. My arguments are particularly solid....however you've got a couple of things to worry about:
(1) users who don't have cookies turned on - therefore stopping the session id or client ids being stored on the local machine. If you are then solely relying on IP address to keep session management (for SESSION vars) then this could also be a problem (see below). If no cookies are turned on then unless you are passing URLTOKEN in the URL then your client vars will not be "saved" - afaik. (2) if you are relying on IP addresses to keep session management then this is where a lot of the SESSION hijacking that used to happen with CF4x would happen. This would only happen (afaik) if multiple people were coming through proxies and so "appeared" to have the same IP address - thus causing SESSIONs to get hijacked. I could be completely shooting off here, but this is my understanding of why it all happens, and the problems with it. I'm sure Spike will put us right soon enough!! ;) In my opinion passing a unique "token" in the URL is a sure way of ensuring that a user has their session and not someone elses. It's a hassles passing tokens around everywhere, but it does make me feel a bit more sure! Just my 2p. Locking your sessions could help, but I didn't think that locking sessions vars was causing session hijackings - just server crashes!! ;) However, I could be wrong. If I am, I'd love to hear the definitive answer on how to sort out SESSION vars so they work properly! Just another thing on a side note, one other reason I don't like SESSION vars is that they don't work particularly well with clustered environments, unless you use sticky sessions. However with client vars you can store them in a shared database which would be accessible by every node on a cluster. Therefore if one node does goes down, the user doesn't lose their sessions! > -----Original Message----- > From: Matt Horn [mailto:[EMAIL PROTECTED]] > Sent: Monday, October 14, 2002 9:49 AM > To: [EMAIL PROTECTED] > Subject: RE: [ cf-dev ] addtoken="No" > > > Nik are you saying that all CFapps MUST have cfid and CFtoken > inthe URL to > ensure no session hijacking? > > I disagree > AFAIK > if you lock properly your sessions should never get muddled > > is there some documentation to support your claim? > > *interested* > > Matt > > > > At 09:43 14/10/02 +0100, you wrote: > >If you are using Client variables (or even session vars) not > passing the > >URLTOKEN will sometimes 'cause sessions to go nuts. > > > >You will always need to pass URLTOKEN if you want to > guarantee that your > >sessions will not get hijacked! > > > >If you set addtoken="no" you will then need to explicitly pass the > >URLTOKEN in the string. > > > >Cheers > > > >Niklas > > > > > > > > > -----Original Message----- > > > From: Robertson-Ravo, Neil (REC) > > > [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, October 11, 2002 9:32 AM > > > To: '[EMAIL PROTECTED]' > > > Subject: RE: [ cf-dev ] addtoken="No" > > > > > > > > > Ah, I always set it to no. > > > > > > -----Original Message----- > > > From: Giles Roadnight [mailto:[EMAIL PROTECTED]] > > > Sent: 11 October 2002 09:32 > > > To: [EMAIL PROTECTED] > > > Subject: Re: [ cf-dev ] addtoken="No" > > > > > > > > > I thought that the default was to add a token. If I leave the > > > attribute off > > > I always get the token added. > > > ----- Original Message ----- > > > From: "Robertson-Ravo, Neil (REC)" > > > <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Friday, October 11, 2002 9:25 AM > > > Subject: [ cf-dev ] addtoken="No" > > > > > > > > > > Anyone had any problems where not adding addtoken="no" to > > > the cflocation > > > tag > > > > will cause it to add the token. > > > > > > > > CF4.5x > > > > > > > > Thanks > > > > > > > > N > > > > > > > > -- > > > > ** Archive: > > > http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/ > > > > > > > > > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > -- > > > ** Archive: > http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/ > > > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > -- > > > ** Archive: > http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/ > > > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > For human help, e-mail: [EMAIL PROTECTED] > > > > > > > > >-- > >** Archive: > http://www.mail-archive.com/dev%> 40lists.cfdeveloper.co.uk/ > > > > >To unsubscribe, e-mail: > [EMAIL PROTECTED] > >For additional commands, e-mail: [EMAIL PROTECTED] > >For human help, e-mail: [EMAIL PROTECTED] > > > -- > ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > For human help, e-mail: [EMAIL PROTECTED] > -- ** Archive: http://www.mail-archive.com/dev%40lists.cfdeveloper.co.uk/ To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] For human help, e-mail: [EMAIL PROTECTED]
