Maintaining ColdFusion Sessions Across SMS Text Message Requests Without Cookies

Posted September 10, 2009 at 8:14 PM

Tags: ColdFusion

One of the great features of ColdFusion that makes programming so easy is the way in which ColdFusion seamlessly maintains user Sessions across multiple page requests. It can do this by automatically setting and parsing session cookies; or, it can grab user-supplied session tokens from the URL. In either case - cookies or URL parameters - ColdFusion takes the supplied session tokens and automatically associates the correct session memory space with the current page request.

When your application has access to cookies or URL-based CFID and CFTOKEN values, this works perfectly; sometimes, however, neither of these options are available and maintaining the ColdFusion session across multiple page requests gets a bit more complicated. In my previous posts about using TextMarks to SMS-enable our web applications, I had to explicitly cache pseudo-sessions in the Application scope because neither the SMS protocol nor TextMarks' web proxy service allow for the use of cookies or round-trip URL parameters.

Having to maintain session without cookies is certainly a pain. But, that said, as long as the API / SMS text message requests to our ColdFusion application are sufficiently predicable, we can still leverage the implicit session management that the ColdFusion framework provides. The trick to this is in fully understanding when the current request is associated with the appropriate Application and Session memory spaces.

When you make a request to your ColdFusion application, the ColdFusion server creates and utilizes an instance of your Application.cfc component. As this happens, the following series of events takes place (as far as I can theorize based on personal observations and guesstimations):

1. The ColdFusion application server initializes the common scopes - FORM, URL, COOKIE, etc.
2. The ColdFusion server creates an Application.cfc instance and the Application.cfc pseudo constructor executes (this is the code in your Application.cfc that resides outside of any CFFunction tags).
3. The ColdFusion server examines the initialized Application.cfc data to see what Application memory space to access (based on the this.name property).
4. The ColdFusion server examines additional information - cookies and URL variables - to see what session memory space to access.
5. The ColdFusion server triggers the appropriate application event handlers (ex. OnApplicationStart()) defined in the Application.cfc.

The most critical fact to take note of in the time line above is that the Application and Session memory spaces are associated to the current page request after the pseudo constructor has executed. We can traditionally leverage this fact to define request-specific session properties such as dynamic management and session timeouts. But, even cooler than that, we can use the pseudo constructor space to create custom session tokens before the current request is even associated with a session!

Previously, I stated that our requests needed to be sufficiently predictable before we could use this technique. By that, I mean that each unique user does need to pass something unique (but consistent) to your application. Perhaps that's an API key or an IP address. When dealing with the TextMarks SMS web proxy, we can configure our URLs to pass through the ID of the cell phone. This is a value that TextMarks assures us is unique to each phone and consistent across each request. The following is the URL I have configured:

http://www.bennadel.com/resources/demo/textmarks/session/ind ex.cfm?uid=\u

As you can see, the "\u" requires TextMarks to pass through the unique phone ID with each proxied SMS text message request.

Once we have this unique value, we can use it to forge our own session tokens. All we have to do is create a CFID and CFTOKEN value and put them in a place where ColdFusion will look for them when trying to associate the current page request to the appropriate session memory space. Since ColdFusion session management works most naturally with cookies, I chose to put them in the COOKIE scope. In the following Application.cfc, I use the pseudo constructor and the url-based phone ID to create usable session tokens:

Application.cfc

 Launch code in new window » Download code as text file »

As you can see above, I take the url parameter, UID, and use it to create user-specific CFID and CFTOKEN values. Not only will ColdFusion use these customized CFID and CFTOKEN values to associate the request with the correct session memory space (effectively enabling session management), because ColdFusion will use the same tokens across session timeouts, this works just as well with the first request as it does for all subsequent requests.

While this application is meant to be used in the context of cellular phones only (and TextMarks specifically), I have added some additional logic around the CFID creation to help prevent session collisions. Since the standard CFID value is only 4 digits when created by a cookie-based user, I know that by creating a 5+ digit CFID value for SMS-based requests, the phone-based sessions will never collide with the standard, web-based sessions.

To test this out, I created a very simple front-controller that counts the number of requests made by a given cell phone user and then returns that count in the TextMarks response:

Index.cfm

 Launch code in new window » Download code as text file »

As you can see, this front-controller operates as if the implicit ColdFusion session management is intact; and, it can do so because the ColdFusion session management is working as expected. The front controller increments a session-based "hit count" variable that was initialize in the OnSessionStart() event handler, and then creates and returns the response HTML.

When you use a technique like this, of course, there are going to be some security concerns. After all, we are taking several numbers that should be randomly generated by ColdFusion and reducing them down to one, url-based value. This would make brute-force guessing of someone else's session token somewhat easier. That said, all the good security practices that you put in place with a standard ColdFusion application can still be applied here; and, all the precautions you might normally take to ensure someone isn't brute-force guessing session tokens are all still valid.

The ColdFusion application framework is extremely robust and hugely flexible; this gives us as programmers a tremendous amount of power. The trick to harnessing that power, however, is to really understand how the ColdFusion framework works and how page requests within it are processed. Once you understand that, there's a whole world of functionality waiting to be hooked into.

Download Code Snippet ZIP File

Post Comment  |  Ask Ben  |  Permalink  |  Other Searches  |  Print Page

• Add To Del.icio.us
• Add To Digg
• Add to Spurl.net
• Add to Wists
• Add to Simpy
• Add to Newsvine
• Add to BlinkList
• Add to Furl
• Add to reddit
• Add to FARK
• Add to BlogMarks
• Add to Yahoo! My Web
• Add to smarking
• Add to Ma.gnolia
• Add to Segnalo

Reader Comments

Wow. You're really taking this to the next level. Great work!

@Aaron,

Thanks man. I thought this was a very interesting post, SMS or not. The ColdFusion application framework let's us do some sneaky stuff!

Great hack. This doesn't seem to work on Railo though. The session doesn't stick across requests. Anyone have any suggestions?

@Dave,

Hmm, that's not good. This seems like a core piece of the ColdFusion application framework. I'm surprised this doesn't work.

Yeah, works fine when running the above in a browser (hitting index.cfm?id=12345), but fails to maintain the session when I do a cfhttp get to the page.

@Dave,

Sounds like a bug in Railo.

@Ben / Dave: It's not a bug. CFHTTP does not pass cookies back to the request to persist the session. You have to use cfhttpparam to do so. In Ben's code above, he's using ?id={MADE UP CFTOKEN VALUE} above and the phone browser is passing that value around, Ben is not using cfhttp.

@Todd, @Dave,

Perhaps I misunderstood what Dave was saying; I thought he meant he was hitting it via CFHTTP passing in the made up token (and session was not being held across CFHTTP requests)?

No, Ben has accomplished exactly what I am attempting to do on Railo (and have successfully done on CF8). Ben's example uses textmarks which I'll assume posts incoming sms messages to a CF url Ben specified. Attached to that url is a unique ID (probably phone number). As I understand it, Ben is using that unique ID to specifically set the CFID and CFTOKEN cookies on each request eliminating the need to pass url params around. So the above example works fine on CF8 and not on Railo. Thanks for the help Todd!

@ben yes, that's exactly what I am saying

@Ben: Currently waiting to see some code from Dave. For all I know, you probably can't generate your own CFID/CFTOKEN in Railo. I won't know until I see / test. In my testing, if I just made up numbers Railo didn't like it and made new ones for me. If I took the CFID/CFTOKEN that Railo created and gave them back to Railo, it was happy. Perhaps it's a security feature.

@Todd: Yes, I think that's exactly what's happening. Using Ben's example above I log the value of cookie.cfid right after I set it and it is inded the value I set. In index.cfm I log cookie.cfid and it is indeed different.

@Todd,

Yeah, sounds like a bug (or simply a difference) in the way Railo handles session management.

@Dave: Well, Ben did say in his video that it was a bit of a hack. :D

@Todd,

Touche ;)

Not sure how it's a bug, definitely a difference. I don't want my users or coders creating their own CFID/CFTOKEN. That's the server's job.

@Todd,

I mean "bug" only in the sense that it deviates from the way "Adobe ColdFusion" implements it.... only so far in that Railo is an open-source version of ColdFusion.

I guess it depends on what you feel is "core" ColdFusion functionality.

Is there no unique (device or otherwise) id that gets passed in the request that you can shove into the application scope?

@Todd,

Yeah, each phone has a unique ID; this is the value that is being used to hack the custom CFID / CFTOKEN session values.

My opinion is that I don't think auto-generating your own CFID/CFTOKEN is recommended. I'll have to wait for Micha to answer what the ramifications are, but he probably didn't allow this in Railo for a reason and I can't say I blame him. There are some "features" that work in ACF that Railo team just flat out refuses to acknowledge and takes a strong stance in the name of security or memory. This may be one of them.

Seems to me that your statement from above is the way to go: "I had to explicitly cache pseudo-sessions in the Application scope because neither the SMS protocol nor TextMarks' web proxy service allow for the use of cookies or round-trip URL parameters."

You'd have to watch out for race conditions which means using your <cflocks> wisely.

@Todd,

That's understandable. I am not sure if this really leaves any more security holes than the fact that using old cookie-based CFID / CFTOKEN values will create a new session using the old CFID / CFTOKEN values (unless this is also something that Railo has also excluded).

Storing the session data in the application scope is something that I tried in the post before this one. It works... but I just thought there was something so graceful about being able to tap into the implicit session management provided by the CF engine :) Not necessary, just a perceived elegance.

Case in point, Ben, you may not be aware of this, but in Railo - OnApplicationStart() & OnSessionStart() act differently than in ACF.

ACF does:
OnApplicationStart (1st hit)
OnSessionStart (1st and each hit thereafter)
OnRequestStart (each hit)
OnRequest (each hit)
OnRequestEnd (each hit)
...

Railo does:
OnRequestStart
OnRequest
OnRequestEnd
...

When Railo encounters the 1st <cfset session.{blah} = {whatever}> or <cfset application.{blah} = {whatever}> it fires off OnSessionStart / OnApplicationStart. I heard talks of Railo making this a setting, but so far... it hasn't been heavily pushed because you can get around this by putting: <cfset session.foo = 1> in your OnRequestStart() and everything works as ACF would.

You are probably thinking, why the hell would Railo deviate like that? Answer: Spiders, Crawlers, Bots. Why burn the application memory usage of your server with these requests? Some of these spiders, crawlers and bots are legitimate (indexing), so blocking them does no good.

Ben, you can ramp up the security by turning on J2EE session which gives you a third set of numbers other than CFID/CFTOKEN. There's a reason why ACF put this in place (other than just session replication).

@Todd,

I have seen tidbits about the way Railo handles session. I can understand that it lazy-loads sessions, but I also think that I might make some things more complicated. For example, often times, I like to track the user's point of entry to a site (what page the landed on, where they came from); but, if session management is delayed beyond the initial page, it seems like you'd have to find a hack to store that data.

I suppose each engine will have its own strengths - let's not let this spiral into a ACF vs. Railo debate :) The real trick is finding ways to most leverage each of the differences.

Ben, sorry if I didn't make this clear. You can make it work like that if you want, just put <cfset session.foo = 1> (and <cfset application.foo = 1>) in your OnRequestStart() and it reverts to ACF's way of doing it and I mentioned there's talk of making it a setting so the developer can choose.

@Todd,

Ahh, gotcha, yeah that makes sense.

@Dave: I talked to Gert he suggested:
<cfhttp method="get" url="http://{some cf website}" result="stuff" addtoken="yes" />

Note the addition of cfhttp attribute addtoken. That should persist your session without having to create your own CFID/CFTOKEN. They developed this for a client that had to do the same thing. :)

Post Comment  |  Ask Ben

Post A Comment

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Formatting: <strong>bold</strong> <em>italic<em>
	Remember my information
	Subscribe to entry *
	Send me a copy of this comment (as part of the comment thread)

 

* If you subscribe, any new posts to this thread will be sent to your email address.