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:
- People who have cookies disabled can still use your application just like people with cookies enabled.
- Users can use multiple browser instances to log into multiple application accounts simultaneously.
#1 is pretty straightforward, but #2 requires some additional explanation.
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.