Save session when calling from another website

Question

I have two websites: website1 and website2 .

Website2 has a login page. When the user clicks the login button, he will call the HTTP handler on website1 to authenticate the user. On successful authentication, user information will be stored in the Session variable from the handler.

It then redirects to page1.aspx on website1. But a previously established session is not available in page1.aspx. What is the problem?

I checked the session identifier in the first request (when calling the handler on website 1 from webiste 2) and the second request (redirecting to page1.aspx from the handler), the session ID is different.

How to save session data?

Answer 1

You need to save the session data in another process shared on both websites. You can do this in many ways:

• SQL Server Setup
• Configure the SessionState service, the Windows service used to exchange information.

In both cases, you need to modify both web.config files to support the new session mode. That is, to use SQL:

Prepare the database (from the command line):

cd \Windows\Microsoft.NET\Framework\v4.0.30319 aspnet_regsql.exe -ssadd -E -S localhost\sqlexpress 

Modify the web configuration as follows:

 <sessionState mode="SQLServer" sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/> 

You do not need to change your code.

Answer 2

Correct me if I am wrong, different AFAIK domains cannot use the same session. One way to handle this is to transfer data to another site using a cookie [encrypt security values], and then copy this cookie value to a session on another site, receiving it and destroying the cookie.

And if the sites are on different servers, you need to handle the “sticky session” so that the servers share the session.

Answer 3

This situation seems similar to the one that I have already encountered and worked before, when one web application acts as a login page, and the other is the actual application where all your work is done. I can describe what I did in the hope that you find it useful.

Like you, I had one web application that had a login page (so in your example it would be website2 ). When I submit the login form, I redirect to the fake Login.aspx page in website1 - this is where we differ. I think, since I'm not sure about your specific reason for using the HttpHandler .

In my case, the page website2 Login.aspx is actually located in the web application; it does not have markup, only code that will authenticate the user, perform customization (for example, set session variables), and then redirect to another page such as Homepage.aspx . This particular scenario worked for me, so maybe your problem is using the HttpHandler , although I would not be able to tell you why.

Answer 4

To maintain the same session date on two different servers running ASP.NET web applications, you must configure the session state to control from the process. This means that the actual session state data variables will be stored outside the workflow and in another process that can make the session data available to other machines.

To do this, you can configure the application to use SQL Server to store session state and make it available to multiple servers in your farm. The TechNet article Configuring SQL Server for Session State Support (IIS 7) provides more information about this in IIS 7.

If you are using IIS 6, the steps for configuration are slightly different, and I can provide more information about this if necessary.

For this to work, you need to make sure that both servers run applications in the same domain, for example. myapp.com, otherwise the ASP.Net session cookie will not be passed between the two servers. ASP.Net uses a cookie to look up the state of a session stored in SQL Server, and therefore cannot find the corresponding session if the cookie is not passed on requests between two servers.

Answer 5

I think that IRequiresSessionState will not help, because the context is different. as soon as we encountered the same problem, but passed the asp session variables to .net. How can you do this here. on both sites create the page setsession.aspx now, if you are on the page, say web1 / page5.aspx and want to go to web2 / page3.aspx are you redirecting to web1 / setsession.aspx? togo1 = web2 / page3.aspx in setsession.aspx logic to retrieve sessiondata data and place it in querystring

so will web1 / setsession be redirected to web2 / setsession.aspx? sess1 = value1 & sess2 = value2 & togo = page3.aspx

web2 / setsession.aspx will check the request for querystring, and if found will retrieve all the names and value of the request, it will be set in the session and then redirected to the togo value.

you need to distinguish between togo1 and togo carefully.

Answer 6

Sharing sessions between sites will require manual coding. You could hack the asp.net framework to get this working, but I feel that this is not an easy way to achieve what you have outlined.

If user authentication is all you do from a website, is there an alternative? Single sign-on mechanisms will help you here.

Something like SAMLSSO might help you in this case.

Answer 7

You have two websites hosted on different servers, which means that there are two different processes on different computers, so the sessions will definitely be different. The same session cannot be shared between processes, because by default asp.net maintains a session in memory.

Here you need to think about saving session information that can be shared between two processes (i.e. outside the process). An ideal way to store session information in databases. To do this, you can consider the Stefano Altieri code example above.

Answer 8

I don’t think you really want to share session information between the two websites. From what I can extract from the comments, what you are really trying to do is authenticate the user on one website (give you a username and password that are verified), and then transfer this state “to the system” to another website, 'handle authentication for yourself.

What you are describing is a delegated authentication model.

In this model, the authentication of your application is performed by other systems on which it hopes to provide information about users.

There are two well-known protocols that provide this mechanism:

Openid
This is intended to facilitate user login using their own identity providers (Google, Facebook, Microsoft Account). This is a very good choice if you use a public website, as most users already have an account with which they can log in.

WS-Federation
This is designed to make it easier for users to log on with identity providers managed by well-known trusted parties, such as partner organizations.

In version 4.5, the .NET Framework has built-in support for WS-Federation through the Windows Identity Foundation component (and is also available for earlier versions as a separate download). This automates the task of delegating your authentication to the identity provider.

It also provides components for writing your own identity provider if you want to create your own, but you don't need to; You can find various existing implementations to do the job for you.

---

The problem you are trying to solve is very complex, especially trying to make it reliable enough to be reliable. The good news is that smarter people than you have spent years developing very smart ways to do this. You should use what they did, and not try to combine something from the session state.

In the long run, it is best to let smart men work hard for you.