Last post Jan 26, 2011 06:03 PM by kendallb
Jan 24, 2011 11:03 PM|kendallb|LINK
I am on the final stretches of putting together a complete system to get our new ASP.NET MVC code to co-exists with our legacy PHP code. By co-exists I mean that the PHP code and ASP.NET MVC code can both run on the same web site, and can share data. So
we can add new code to the site using ASP.NET MVC, but still have the legacy PHP code working until it is replaced. The key to getting all this to work was to build a system to share session state between ASP.NET and PHP. Since both systems store the session
data in different formats, the solution we landed on was to isolate key session variables that need to be 'shared' between the two code bases, and put those into a special shared section in our session tables, encoded in a common format. I am using JSON to
encode the shared session variables, and now that I have it all working so that the ASP.NET and PHP code can both grok the same JSON formatted data, everything is working. Well, almost!
The problem I have run into is related to the session ID's. In PHP, if we have an existing session ID in the session cookie we tell PHP to go ahead and use that value, using the session_id() function:
So the PHP code will happily use a session ID that was generated by the ASP.NET code, once we tell it to use that value. Clearly we had to override the session ID cookie on both PHP and ASP.NET to use the same cookie value, but once that is in place, PHP
will happily pick up an existing ASP.NET session and start sharing it. The problem is it does not go the other direction; both PHP and ASP.NET use different algorithms to generate the session ID's, and PHP generates one that is 26 characters long and ASP.NET
generates one thast is 24 characters long. But they are both unique.
The catch is that ASP.NET appears to be doing validation on the session identifier and can tell when the identifier was NOT generated by ASP.NET, and it won't use it. Rather it will simply generate a new session identifier so we lose all the information
that was in the original session.
So right now everything works great if you first land on an ASP.NET page to start the session, but it all falls apart if you first land on a PHP page, or more importantly at the moment if you do a login via the PHP code because that code regenerates the
session during login. Then the first ASP.NET page you hit after that will generate a whole new session, so we are back at square one.
So, to solve this problem there are really only a couple of options:
1. Find some way to tell ASP.NET that I *want* it to use the session ID I provide it, much like the session_id() function works in PHP. If I can do that, I can solve this very easily, but I cannot find anything that would indicate it is even possible.
2. Somehow write some PHP code that can generate a session identifier that is compatible with ASP.NET code. To do that, I need to find out what algorithm is used to generate the session identifiers in ASP.NET, so I could port it over to PHP.
3. A hack solution related to option 2) would be to have a special ASP.NET page that does nothing except generate a new session, and return the valid session identified to the caller. I could then call that with CURL from the PHP code when it needs to generate
a brand new session ID, so that the session ID that is used will be accepted by ASP.NET.
4. Completely replace the entire session module in our ASP.NET code with a custom session module. I know it is possible, and most of it is already done with our custom session state provider anyway, but then I still need to find some code to generate a solid
session ID anyway!
Any suggestions on how to solve this problem?
Jan 26, 2011 01:17 AM|Wenchao Zeng - MSFT|LINK
You are an advanced user.
I think option 1 is the best. I would suggest implementing your own
SessionIDManager by referring to ISessionIDManager Interface.
If you only want to supply custom session-identifier values to be used by ASP.NET session state, you can create a class that inherits the SessionIDManager class and override only the CreateSessionID and Validate
methods with your own custom implementation. This enables you to supply your own session-identifier values, while relying on the base SessionIDManager class to store values to the HTTP response and retrieve values from the HTTP request. For an example of overriding
the SessionIDManager class and implementing these methods, see the example provided for the CreateSessionID method of the SessionIDManager class.
Hope this helps.
Jan 26, 2011 04:27 PM|kendallb|LINK
Awesome, thank you very much! I will take a look at that. I want to use ASP.NET to generate the session ID's when there is no session ID already active in a cookie, but if a session ID is already there (which comes from PHP), I would like to be able to ensure
it gets used and not blown away. So I think that might work great :)
Jan 26, 2011 06:03 PM|kendallb|LINK
Excellent, that worked great. All I needed to do was make a new subclass of the session ID manager, and overide the validation function. Then when the validation fails, I check if it looks like a valid PHP session ID (basically 26 characters as PHP does
not do much other validation), and the I accept that. Works nicely :)