views:

401

answers:

3

I am trying to fix an ASP.NET site that a friend had botched converting from older technologies. To the user, the site appears to have public and secured sections. Behind the scenes, the public and private sites are separate web applications with separate app pools. The difficulty arises because it appears that the applications share the same session IDs (when going from the public to the secured pages, the session ID remains the same), yet none of the (InProc) session variables are getting passed from the public site to the private one.

Basically, the workflow consists of the user checking a checkbox ("I agree" type of stuff) on the public site (let's call that page http://www.boring.gov/iAgree.aspx), then logging in on the secured site (let's call that page https://www.boring.gov/login.aspx). The commandments from the parent agency in DC are that the user may not bookmark the login page, the user has to click "I agree" every time they log in, and that the "I agree" stuff has to be on a separate page.

What am I missing?

How would you do it?

Notes:
1 - This is getting hosted on a single Windows 2003 server.
2 - Yes, it is a government agency.
3 - I would have done things very differently if I was doing the conversion, but I wasn't brought in until the poop hit the fan, and it is too late to redo things.
4 - Two previous SO threads that appear to be related, yet don't apply are this and that

+1  A: 

In your current scenario you aren't going to be able to use the same in proc session variables. Since the two sites are different applications, they can't share in memory information.

I would try serializing the information you need to a database, so that both applications can retrieve variables.

Kevin
+1  A: 

You need to use a machine key in your web config file and hits needs to be the same in both your applications. When a request is made for session info this machine key will cause it to fetch the same data. We use this in a load balancing scenario where the application needs to be getting the same session info regardless of which server is responding to the user request.

A typical key might look like this.

<machineKey     validationKey='A130E240DF1C49E2764EF8A86CEDCBB11274E5298A130CA08B90EED016C0 
14CEAE1D86344C29E67E99DF83347E43820050A2B9C9FC89E0574BF3394B6D0401A9' 
decryptionKey='2CC37FFA8D14925B9CBCC0E3B1506F35066FEF33FEB4ADC8' validation='SHA1'/>

Check out this for more info.

Middletone
A: 

Not sure what kind of stuffs you want to share between 2 versions. If you wanna share immutable information such as username, userid... you just need to redirect (or POST) from HTTPS to the HTTP version and send those variables a long this request (either in URL or HTTP form) (*). If your stuffs are subjected to change all the time, you should serialize those variables to a persistent area (files or DB).

(*) If those stuffs are sensitive, use server side requests instead. The receiver supports a "web service" (a Restful based HTTP GET/POST, not SOAP I mean) for the other (caller) to update its variables. Of course we should restrict callers from localhost only.

instcode
It is really just a simple variable that says "I checked the box" and redirecting them to the page where they can check it if they didn't - such as if they bookmarked the login page. Passing things in the query string is forbidden by policy.
Tangurena
What if those things are encrypted, i.e using session-id (so it won't necessarily be the same between 2 sessions)? You could see in some SSO webapps, the authentication tokens are passing around in the redirecting URL and nobody complaints that :-)
instcode