A couple months ago at work we had our first shot at writing some cool and "modern" AJAX powered features on an administrative tool. Not being a newbie to website security, I had some pretty high demands about keeping it safe. It's a given that when you're building Internet applications at a school that teaches Web Design and Development you need to build stuff right.
The challenge was that I wanted to make sure only folks who were authenticated as administrator role users had access to the remote-accessible methods in the service CFC. My first thought was of course to try to identify the authenticated session. For some reason, however, the CFID and CFTOKEN were completely unavailable in the XmlHttpRequest call (AJAX). This confused me, but I had my hands full with other things and didn't dive in too much. Instead, a separate system involving an AccessEvent object and some uuid() keys was invented and it works quite well. Probably even overkill, if there is such a thing regarding security.
Well, tonight I started working on something that would work in a similar way, unrelated to the aforementioned effort. This was my chance to dig in a little bit and find out why the CFC being hit via AJAX wasn't seeing the session. Now, we know that it's the browser's two cookie values that identify the session to ColdFusion. And I knew that the XmlHttpRequest was sending those in the HTTP header. So why no session?
Virtual Directory / Alias
Yep, should have known. ColdFusion is sometimes a little smarter than we give it credit for. In the project at work, we were hitting a CFC that has an alias (NOT a ColdFusion mapping!) at the web server level to make the file accessible via an HTTP call. However, ColdFusion knows that it's physical location on the local drive is not in or under the same directory that the Application.cfc file is in. Therefore, this service CFC is not permitted to read the session or application, not in any way, because it is in fact not a part of the application. Case closed.
The solution here is to create a service layer local to the application that acts as a wrapper for the other CFC file(s). In fact, as I think it through some more, the service CFC we've got outside the application root doesn't even belong out there. It's specifically a service for the application, and were its job to include access from other applications, the parameters and other security concerns would probably change. This in effect renders it "non-re-usable" in my book. I now believe the answer here is to move that service layer into a local CFC / service folder, inside the confines of it's owning application.
Or... I'm wondering now... would making an application mapping to that outside folder bring it into the fold and allow it to see sessions? Now that's something I'll have to try.
Recent Comments