Yikes, that's a long one - not really what I was after but interesting anyway.
On another tiny side-note: ----------------- > Small side note - I've heard people say that CFID/CFTOKEN is insecure because people sitting in the middle > (like at an ISP) can sniff the URL & hijack the session. Well cookies are no different, > the information is still going across the wire in plain text & anyone who can look at the > HTTP headers can hijack the session. The only way to secure sessions is the use HTTPS. ----------------- I reckon it has nothing to do with CFID/CFTOKEN any session identifier from any language is interceptable to this kind of hijacking. I reckon you can make it a bit more difficult by looking at the remote IP or xhttp_forwarded_for (I believe that's what it is) if behind a proxy. I know, still not 100% secure, but securer... ----------------- > The only way I can see this happening is that you might have been passing CFID/CFTOKEN values > through the URL. If I have a URL that looks like http://www.domain.com/index.cfm?CFID=XXXX&CFTOKEN=XXXXXXXX > and I posted it to this mailing list - everyone who clicked the link would be the same client as > far as CF server was concerned & pick up the same session variables because they are using the same PIN number. > > So if you are testing in two browsers in this way you are going to get the same problem. However if you > clear the CFID/CFTOKEN off the link there is no way that your session in Netscape is going to be shared with your session in IE. ----------------- I should have posted the whole thread I was talking about, someone said that if you open a browser and start a session, then open a new browser, not by clicking file -> new, but by actually clicking the browser icon again and opening a new browser and start another session - you can maintain two sessions, I thought it was a bit weird myself, but other people confirmed if I am not mistaken.. Taco Fleur Blog http://www.tacofleur.com/index/blog/ Methodology http://www.tacofleur.com/index/methodology/ 0421 851 786 Tell me and I will forget Show me and I will remember Teach me and I will learn > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Mark Stanton > Sent: Tuesday, 20 January 2004 6:33 PM > To: CFAussie Mailing List > Subject: [cfaussie] RE: Old Post RE: Browser Sessions - elaborate > > > This is (not so) briefly how I understand the session & > client scopes in CF: > > Session variables: > Session variables are stored in memory on the SERVER. Each > session is referenced by a unique session identifier > (JSESSIONID or CFID/CFTOKEN pair). > > HTTP is stateless, there is no inherent way to say "this > request is part of that session". So in for the server to > work this out some information has to be passed back & forth > between the server & the client on each request/response. > This information is the session identifier (JSESSIONID or > CFID/CFTOKEN pair). > > The first time a browser hits a CF page the CF server makes a > new session, creates the session identifier & gives this back > to the client, this is kind of like the session PIN number. > The client then uses from them on to access its session on the server. > > On each subsequent request the client sends this session > identifier along with its request (POST or GET) and the > server can then match the request up to the session. There > are two ways that this session identifier can be sent back; > either in the URL or in the HTTP headers as cookie data. This > might look something like this when it goes over the wire: > > Cookie: JSESSIONID=96301828141074585835953; > CFTOKEN=9c76f3e1c540c048-324E99B1-E168-32E6-4F58135858045667; > CFID=211501 > > > Regardless of which method is used the server looks at the > PIN, works out if the session is valid and if it is it will > use the relevant session variables. > > Ok so what is the difference between using cookies & or the > URL. Well some fools don't allow cookies in their browsers > and/or some developers can't work out how to support IE's > privacy policies correctly (its not exactly easy but you can > usually get around everything but the highest privacy setting > if you implement P3P - www.w3.org/P3P/). When cookies fail > you can revert to passing CFID/CFTOKEN through the URL. > > At the end of the day there are really no major differences > in terms of security or anything else. > > Small side note - I've heard people say that CFID/CFTOKEN is > insecure because people sitting in the middle (like at an > ISP) can sniff the URL & hijack the session. Well cookies are > no different, the information is still going across the wire > in plain text & anyone who can look at the HTTP headers can > hijack the session. The only way to secure sessions is the use HTTPS. > > Client Variables: > Client variables pretty similar to session variables in most > ways. The main difference is that they persist (where as > session variables exist in memory & expire after a certain > period). Storing client variables in the registry or a > database is pretty much the same thing in terms of what we > are discussing now - the key point is the values get stored > on the server. Storing client variables in a cookie means > that you actually send them all back & forth between the > browser & server on each request. > > I think that is pretty much session & client scopes in a nutshell. > > > > <quote>Because the session is being tied to the "Client" > itself - i.e. > > the actual browser. If you try the same thing but with a different > > browser on the same machine it should work correctly.</quote> > > > > I tried it myself and did not get this to work, did anybody else? > > The only way I can see this happening is that you might have > been passing CFID/CFTOKEN values through the URL. If I have a > URL that looks like > http://www.domain.com/index.cfm?CFID=XXXX&CFTOKEN=XXXXXXXX > and I posted it to this mailing list - everyone who clicked > the link would be the same client as far as CF server was > concerned & pick up the same session variables because they > are using the same PIN number. > > So if you are testing in two browsers in this way you are > going to get the same problem. However if you clear the > CFID/CFTOKEN off the link there is no way that your session > in Netscape is going to be shared with your session in IE. > > > > Can anyone elaborate on the following "particular client and > > application and that must be saved between user sessions" > > Client variables persist (as I mentioned before) so if I log > into a site tha t supports them, then go away & come back a > week later my session will be long gone, but my client > variables should still exist. This makes client variables > good for things like "Remember me" functionality or tracking > when I last visited the site & how many times I've been to > the site. In fact coldfusion even does some of the work for > you by automatically providing client.hitCount, > client.lastVisit & client.timeCreated. > > Client variables are application specific, so if I have one > CF server with 3 apps on it I'll get unique values in my > client scope for each application. > > hth > > > Cheers > > Mark > > > ------------------ > Mark Stanton > Technical Director > Gruden Pty Ltd > Tel: 9956 6388 > Mob: 0410 458 201 > Fax: 9956 8433 > http://www.gruden.com > > > --- > You are currently subscribed to cfaussie as: > [EMAIL PROTECTED] To unsubscribe send a blank email to > [EMAIL PROTECTED] > > MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004 --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
