We Keep Coding

Web Tokens and HttpSessionState ASP

Good day,
Is the following a good solution or is there alternative or is this bad.
I have a ASP MVC client application and it talks to a HTTP API (also Microsoft but does not matter).
In my client application I'm storing session data (HttpSessionState) for data the user is busy with (cache). Obviously the session data is stored against a session ID which is the instance (session id per client browser). My first problem to overcome is I need to store data using a Unique key for the user (application user) so that I dont override or remove cache if theres more than one logon in the browser. I might have internet explorer open with multiple sessions to the application. This might be the same user two instances or two sessions different session.
When I authenticate the user I have a ID/webtoken. Could one use this as the identifier and store cache with that key included, So if the user logout the cache is clear only for that "logon". Remember this is HttpSessionState which is stored on the server not client browser.

You will not be able to login to two different user accounts in one session as you have only one Authentication cookie shared between all your open tabs. If you open another session, no matter if the user is the same or different you will have a different session id so you will refer to a different session data.
Also remember to secure your WebAPI using tokens as cookie authentication is not recommended and valuable for XSS attacks.

Session ID changes in each Request

I have an asp.net application in which i redirect from one page to another. I'm validating the SessionID in the second page to make sure both requests are of the same session. Now, my problem is the SessionID changes whenever a Postback is happened.
Now, I added the Session tag into my web.config
<sessionState mode="InProc" cookieless="true"/>
Now, the problem with the session was solved and a new issue started appearing. Whenever i make a call with Cookiless="true" in my web.config file, my URL shows a junk address
http://localhost:10766/(S(ojbcobj0aw0wiosttgpknwby))/registration.aspx
If I remove the Cookieless tag the session will be lost in the next page?
Do anyone know why is this coming and if any fix is there for this problem?
I went through lot of threads but i couldn't find a proper fix for this.
EDITED:
I Set my cookieless="false" and now its working fine.

.NET Framework has 05 (five) session state modes:
InProc mode, which stores session state in memory on the Web server. This is the default.
StateServer mode, which stores session state in a separate process called the ASP.NET state service. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
SQLServer mode stores session state in a SQL Server database. This ensures that session state is preserved if the Web application is restarted and also makes session state available to multiple Web servers in a Web farm.
Custom mode, which enables you to specify a custom storage provider.
Off mode, which disables session state.
Now i need to know exactly what does your application do to recommend the better solution:
Do you store something in Session?
Are you using multithreading?
How many servers your farm will have (when the application go live)
Does your app connect to database?
If you keep your original web.config, by default your application will use InProc mode and will store session id on cookie, unless your browser or local server denied it.
I'm waiting to the answers to complement my post.
Reference:
http://msdn.microsoft.com/en-us/library/ms178586.ASPX

ASP.NET FormsAuthentication: have to log in again when restarting application

I have an ASP.NET application using FormsAuthentication. Whenever I restart the application or web server, my authentication token is invalid and I have to log in again. What's going wrong?

By default, FormsAuthentication validates authentication data on every request by having the client store an encrypted copy of the data. The encryption key is stored in Machine.config. The specific key to use is in <machineKey decryptionKey="YOUR KEY HERE">.
If you do not provide a decryption key, one is automatically generated on application startup. Since it is randomly generated, it will be different each time you restart the application. On the validation phase, FormsAuthentication attempts to decrypt the authentication data and fails. Then the user is no longer logged in.
There are two ways of resolving this problem.
Providing a machineKey in Machine.config will give FormsAuthentication a consistent key to use, so validation will succeed with the encrypted cookie from previous application runs.
Using <forms protection="None" ... /> in Web.config will disable authentication data encryption and validation. This is insecure and only appropriate for development, since it will be trivial for users to impersonate each other.

The default session state mode in asp.net is in-proc (cached in-memory) unless you specify otherwise. When the application shuts down, memory is cleared and the in-proc session cache is therefore lost.
#dhasenan The machinekey config will only be an issue if the application is deployed across a web farm or the cloud. The idea of overriding the machine-level config of the Machinekey element is to ensure that multiple machines are using the exact same keys.
Therefore, the machine key shouldn't be an issue because if one is not provided at the application level, the machine key in the machine.config will be used instead, which is persisted and static, so it will not be regenerated between sessions.

Retain session when calling from a different website

I have two website consider it as website1 and website2.
In website2 there is a login page .When a user click on the login button it will call a HTTPhandler in website1 to authenticate user.On successful authentication user information will be stored in a Session variable from handler.
Then it will redirect to a page page1.aspx in website1.But the previously set session is not available in the page1.aspx .What will be the issue?
I checked the session id in first request(when calling handler in website 1 from webiste 2) and Second request( redirecting to the page1.aspx from the handler) the session id is different.
How can i retain the session data?

You need to store session data in another process shared to both web site.
You can do it intwo different ways:
Configure an SQL server
Configure SessionState service, a Windows service used to share informations.
In both cases you have to change both web.config files to support the new session mode.
I.e. to use SQL:
Prepare a database (from command prompt):
cd \Windows\Microsoft.NET\Framework\v4.0.30319
aspnet_regsql.exe -ssadd -E -S localhost\sqlexpress
Modify web config as following:
<sessionState mode="SQLServer"
sqlConnectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;Initial Catalog=Test" allowCustomSqlDatabase="true"/>
You don't need to change your code.

Correct me if I an wrong, AFAIK different domains cannot share a single session. One way to handle this is to carry the data to the other site through cookie [encrypt the values for security], then copy this cookie value to the session in the other site receiving it and destroy the cookie.
And if the sites are in different servers you need to handle the "sticky session" so that servers share the session.

This situation sounds kind of similar to one I have experienced and worked on before, where one web application acts as the login page while another is the actual app 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 app which had the login page (so in your example this would be website2). When the login form submitted I then redirect to a fake Login.aspx page in website1 - this is where we differ I think as I'm not sure of your specific reason for using a HttpHandler.
In my case the website2 Login.aspx page is actually just the way into the web application; it has no markup, just code-behind which will authenticate the user, perform setup (e.g. set session variables) and then redirect to another page such as Homepage.aspx. This particular scenario has worked for me, so maybe your problem revolves around the use of a HttpHandler though I would not be able to tell you why.

In order to retain the same session date across two different servers running ASP.NET web applications you must configure your session state to be managed out of process. This means the actual session state data variables will be stored outside of worker process and in another process that is able to make the session data available to other machines.
To achieve this you can configure your application to use SQL Server to store session state and make it available to multiple servers in your farm. The TechNet article Configure a SQL Server to Maintain Session State (IIS 7) provides details on hor this is done in IIS 7.
If you are using IIS 6 then the steps to configure are somewhat different and I can provide further details on this if needed.
In order for this to work you do need to ensure that both servers are running applications within the same domain, e.g. myapp.com, otherwise the ASP.Net session cookie will not be passed between the two servers. ASP.Net uses the cookie to lookup the session state stored in SQL Server and will therefore not find any matching session if the cookie is not passed on requests between the two servers.

i think IRequiresSessionState will not help because context is different.
once we had the same problem but that was passing asp session varibles to .net. How ever you can do it here also.
on both website create a page setsession.aspx
now if you are on page say web1/page5.aspx and want to go to web2/page3.aspx
you redirect to web1/setsession.aspx?togo1=web2/page3.aspx
in both setsession.aspx logic in to extract sessiondata and place them in querystring
so the web1/setsession will redirect to web2/setsession.aspx?sess1=value1&sess2=value2&togo=page3.aspx
web2/setsession.aspx will check for togo querystring and if found will extract all querystring name and value will set them in session and will then redirect to togo value.
you need to differentiate togo1 and togo carefully.

Session sharing between websites is going to require hand-coding. You could hack the asp.net framework to get this working, but I feel that this is not a clean way of achieving what you set out.
If user authentication is all you are doing from website, is it possible to use alternative? Single Sign On mechanisms will help you out here.
Something like SAMLSSO could help you in this case.

You have two websites which are hosted on different servers, it means you have two different processes running on separate machines, so sessions will be definitely different. Same session can't be shared across processes because by default asp.net support in-memory session.
Here you would need to think about storing sessions information which can be shared between two processes (i.e. out of process). Ideal way to store sessions information in databases. For this you can consider Stefano Altieri code sample above.

I don't think you really want to share session information between two websites at all. From what I can gather from comments, what you're really trying to do is have a user authenticate in one website (give you a username and password which are validated) and then have that "logged in" state transferred to another website which doesn't handle authentication for itself.
What you are describing is the Delegated Authentication model.
In this model, your application hands-off authentication to other systems which it trusts to provide information about users.
There are two well-known protocols which provide this mechanism:
OpenID
This is intended to facilitate users logging in with their own identity providers (Google, Facebook, Microsoft Account). It's a very good choice if you're running a public-facing website, as most users will already have an account they can log in with.
WS-Federation
This is intended to facilitate users logging in with identity providers which are managed by known trusted parties, such as partner organisations.
From version 4.5, the .NET Framework has built-in support for WS-Federation via 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 an Identity Provider.
It also provides components for you to write your own Identity Provider, should you want to create your own, but you shouldn't have to; you can find various existing implementations to perform this job for you.
The problem you're trying to solve is a very difficult one, especially trying to make it secure enough to be reliable. The good news is that smarter people than you or I have spent years working out very clever ways of doing this. You should use what they have done and not try to cobble together something out of Session state.
In the long-run it's best to let the smarter men do the hard work for you.

Uses for MachineKey in ASP.NET

What different ways are Machine Keys useful in asp.net?
I think the following are correct but thought there may be more.
Multiple applications can use the same cookie
Multiple servers can work with the same viewstate

MachineKey is used for:
ViewState encryption and validation
Forms Authentication (or Federated Authentication) uses this key for signing the authentication ticket
Having a Web App installed on multiple servers requires same Machine Key configured on all of them in order for Load Balancing to work.
To see all details, please refer to: MSDN How To: Configure MachineKey in ASP.NET 2.0

Machine key is also used to encrypt/decrypt the webresources.axd parameters.
Even on a single server the machine key should be configured, because any recycle of the app domain will generate a new key when it is set to auto. This causes the next postback just for pages rendered before the recycle, to cause a viewstate validation error, and also issues with the resources during that time.

Encryption - very common.