Coldfusion 10 : jessionid not working when passed in url

Question

We are migrating from ColdFusion 8 to 10. Our application is having functionality written in .NET as well however the session is maintained in ColdFusion only.

Current architecture in ColdFusion 8 for .NET and CF integration:

1. Session is set when user logs in to the app (In CF). (We are using J2EE sessions.)

2. When a user clicks on a .NET link, Jsessionid,CFID and CFTOKEN are passed to .net page via url. Inside .net code the following steps are done to check session:

   2a. Call a common function which will do a ColdFusion file request (chkSession.cfm) with jsessionid in url.

   2b. chkSession.cfm will return session.UID if available else will return -1. Session.UID will be available if the jsessionid in url is valid.

   2c. .NET page will be loaded if a valid UID is returned. User will be redirected to login page if -1 is returned.

Issue in CF 10:

In CF 10 , always we are getting -1. I read that as part of security enhancement in CF 10, we will not be able to recreate a ColdFusion session by passing cfide, cftoken, jsessionid in the url.

I would like to get your advice on what is the best way to make our .NET functionalties work in ColdFusion 10. Is there any better way to check ColdFusion session from .NET ? One option I can think of is using a database. I looking forward to a solution that can be implemented quickly and is robust.

Answer 1

What I think would work would be to change your .Net client code to send over the JSessionID as a cookie value in its request. That way the functionality you have ought to work again.

It's worth noting that exposing the Session ID in URLs can expose you to certain security vulnerabilities, so it may be something you want to look at avoiding in future.

I have used the database approach you mention also. If you go this route, have the CF code insert a record using a GUID as an identifier and a timestamp for when the record was created. On the .Net side, look up the GUID and only accept the request if the timestamp is from less than X seconds ago, so you don't create a token which will authenticate you for a long time. X needs to be the max ammount of time you think it'll take a client to follow the redirect from CF to the .Net pages, so 2 is likely plenty. You will want to delete used tokens and have a scheduled task to delete 'unused' tokens.