Separating Sessions From Cookies

Cookies are a great way to pass around session identifies (CFID, CFTOKEN, and jsession values), especially when they are managed seamlessly by the server, saving developers a great deal of time and hassle. So if the process works so well and makes developers’ lives so much easier, why would anyone choose to manually encode session identifiers into all URLs and form action values? There are two reasons:

  1. People who have cookies disabled can still use your application just like people with cookies enabled.
  2. Users can use multiple browser instances to log into multiple application accounts simultaneously.

#1 is pretty straightforward, but #2 requires some additional explanation.

If you use cookies to automatically manage sessions, when a user opens a new browser instance and goes to your application, all the domain’s cookies get sent, and you automatically join the same session that is active in the other browser instance (unless you use an entirely different browser as opposed to just a second instance of the same browser). If you have setClientCookies set to “no” in your Application.cfm file, however, and you use the urlSessionFormat function to encode the session identifier into links and form action values, when a user goes to your application in a different browser instance, they will receive an entirely new session, and can easily maintain both session simultaneously.

If you decide to go this route, I would actually recommend not using urlSessionFormat, at least not directly. A better solution is to write you own version, and use your UDF everywhere instead. That way, just by changing one function, you can add or remove arbitrary parameters that get passed around your entire application. For instance, maybe you have a concept of a role or an affiliate, or something that you decide you want every page in your application to be aware of outside of the context of users’ sessions.

This may seem like a lot of trouble just to allow the occasional user the luxury of maintaining two sessions at the same time, but it’s actually a nice hook to have and can sometime get you out of corners you have inadvertently backed yourself into.

5 Responses to Separating Sessions From Cookies

  1. Todd says:

    My concern is security, but exposing the TOKEN and the ID … can’t anyone just monkey around with the URL window and try to change numbers and see if they get an active session? I haven’t tried this before, but I just felt that this was a no no.The only thing I do different is set the cfapplication’s setclientcookie=”no” and then set my own CFID/CFTOKEN cookies on the page.

  2. Matt says:

    I use the session.urltoken in all pages and forms. We elected not to have cookies for session management (firewalls and users who change the browser settings and all).The only thing I hate is haveing to put the URLToken on all pages. I causes cfoutput’s in places that really shouldn’t be necesary.I did enable the UUID for cftoken to try and discourage people from session hacking, and I enabled the JSession identifier for our ERP users to share session with Oracle apps.This seems to work fine.one security thing we use is to store the IP address from the originating session and check it against the IP on every request. This kills people who try to hack sessions from a different computer.

  3. Todd says:

    Matt, isn’t that technique of checking the IP address everytime pretty much bunk against AOL users? Doesn’t AOL give you a new ip address per click? Just curious.

  4. Mary says:

    This seems to work fine?

  5. I’m going to have to agree on with Todd on this one. Security should be on the top of the list. I too wouldn’t feel comfortable if the TOKEN and the ID variables were exposed.