We Keep Coding

Stopping users going to a site, then back to the previous site whilst staying logged in

I've got a strange one to solve today. A client needs their site to not allow people being logged in, going to a different site, then still being logged in if they hit the back button in their browser.
Simple I thought... until I couldn't find a page event that got fired when the back button was pressed from another site.
I thought of just using JavaScript and working with the referrer object, but this won't achieve my goal as I need to access the .NET Membership system and log the user out of their session.
Has anyone got around this problem? If so, how? Any help would be appreciated, potentially I'm just missing something that I could achieve in the Global.asax? If it helps, I'm using .NET 4.5 / C#.
Reasoning:
Due to, say, if one operator went and left their machine unlocked, visited Google, then another operator went on the same machine maliciously and hit the back button to gain access to that operator's logon (the client is very security cautious)

So you would like to log out user whenever they leave your site? You cah have global javascript that sends a request to a server every minute saying "Hey, server, I'm here! I'm user Joe Blogs, i'm still on the site". If the server does not get this message from a user longer than a minute, log them out.
Overriding back button is just not going to work. What would you do if user opens up another tab/window and goes to google there?
Update:
you can try using .unload() from jquery to catch page leave. And destroy the cookies on that event.
However, when the machine is just left unattended, nothing stop malicious user to go grab the access.
Update 2 you can just set very short session life! if user is inactive (or left the page) - log them out. To prevent possible annoyance for logging out when user looking on the screen for too long (fills in very long form) - make javascript to do regular (every 5 minutes) to a server to a dummy page - to keep the session live while the page is loaded.
Here is the source: Force users to logout when they leave my php website?

There is perhaps a "magical" solution for the problem but the key thing here is in the reasoning: Operator A is not allowed to use the site with the credentials of Operator B.
From a client and server perspective there is no way that the server or client (browser) can tell that persons changed seats at whatever moment in time.
That's the problem you have to solve.
But perhaps implementing face-detection is a little over the top?

If you were designing the site from the ground up you can do this by adding a header to specify that you do not want caching.
Cache-Control: no-cache
Pragma: no-cache
But you would then have to have all your site access through a single page. The page need not be displayed the same and can contain different controls etc, but it's content would be decided by POST parameters rather than through the normal ASP.NET model.
e.g. Default.aspx and to navigate you would POST back at least two parameters. One would be the page to navigate to, and another would be an unpredictable token.
e.g. Token=3Zd2f4O61Z&Page=OrderHistory
Upon each page load you would validate the token and page title combination, and if OK you would display the page and generate new post-back data links for any navigation or actions you would like the user to take at that point. If the user were to try accessing the same page with the old token, it would expire the session and then log out the user. This is the most secure way to do this as then clicking the back button would prompt the user to resubmit their post data again. If OK was clicked, the browser would submit it but the server would recognise that the token was now invalid (as it has already been used, and discarded by the server) and then log out the user.
This method also protects against CSRF as you are validating a token in the payload of each request rather than just checking cookie values.
I know this won't help you unless you can reengineer your site, but I thought I'd add this solution in case anyone lands here with the requirement from the beginning.

You can have a landing page of your site to contain nothing by a JS redirect to reals homepage this way when person hits back button he will go back first to the damy redirecting page that move him back to home page.
But it will be possible to override this if user chooses to skip number of pages at once or just opens another window.

Could you provide further information about why exactly is its needed ? I think in your case, there is a possible solution of may be having a separate Database table or field for marking or flagging such users who have been redirected to another site just treat them as signed off and then once they hit your sites URL you can probably check for the flag and sign them back in, automatically.

JQuery unload() function will solve your problems as wel as the javascript window.onbeforeunload...

on Session time out redirect to one of two different log in screens dependent on query string

I have this historic site that is inertly broken and is in the process of being replaced. how ever until the replace site it ready I have to maintain this site.
the Issue is I have a site that needs to know the group code of the logged in user. for example I have two groups Group1 and Group2.
on the login page by default the is simply .../login.aspx and that will store in the session (group = Group1) and if if the use goes to the log in page with .../login.aspx?group=Group2 then they have Group2 stored in the session instead.
the reason for why this was done this way was before my time by it is a very complex login screen for authentication and is needed to set the site up for multiple session variable.
saying this it means that replacing the log in page is not an option at this stage.
what I need to a way that when the session times out the user is directed back to the correct variation of the login page and also to remember the page that they were on so they can be returned to this page.
minimum solution is to have them redirected back to the correct login version, the taking back to the page they were on after resigning is only a "would like" feature.
can anyone point me in the right direction on how to do this, the on Session end event doesn't seem to work as the session is gone at that point so nothing to compare against.

If you can edit the login page, have it store in a cookie group1 or group2 after the login is successful. When the login page loads, check to see if your group cookie is present. If there is one, you can then do redirect to the appropriate login URL.

But you do have SessionID. In a db or other store associate the SessionID with the group.
HttpSessionState.SessionID Property

I don't think you will be able to do this.
As you stated, in the Session_End event (presumably you are using InProc session for this event to be fired) - there is no session to figure out which group the user was in. Even if you could get the session variables, there is no HttpContext in the Session_End event, as it occurs on server, without an Http Request - so you wont be able to redirect.
This event could fire with the site sitting at a screen at which point, Forms Authentication will redirect back to the login screen, or could occur long after the user has closed the browser.
Edit - More information needed
Are you using InProc session and Forms Authentication for the application?
If so, one possible solution is to create an HttpModule that could run before FormsAuthentication would recognise that the Session/Auth Cookie in the request had expired and redirected back to sign in.
As Blam said - if you store the info in another data store - you can get at this from the HttpModule, and do a custom redirect from there.
Be warned that the HttpModule would run for every request, so any Db calls etc could be a performance drain.

How to ensure that Session ID does not expire when new browser window of same website is opened?

I have a ASP.NET website.
Here's what happens:
I open the site and log in.
I open another window of the same site in IE.
When I do that, it takes me to the page which is suppose to be shown when session expires.
So, can you please let me know how to ensure that Session ID does not expire when we open the site in another browser window?
Thanks!

The session is not expiring because you've opened a new window; the new window must not have the cookie used to store the session-id. Most of the time, these cookies are transient or "session" based cookies.
Session cookies may or may not be shared between browser windows, depending on the browser and how you open the new window. For ex., in IE 9, a new window launched using Javascript, Ctrl+N, or Ctrl+T will share session cookies. However, a new window launched by going to File / New Session will not share session cookies.
You also wont see cookies shared between different browsers (for ex., IE and Firefox).

To add a somewhat more simple answer to Michael's excellent response - the short answer thus is "You can't directly achieve this".
But what you CAN do is implement tracking within your application so that you are always aware of what a user's last action was, and no matter what session they come in on, forcibly keep them in your designated workflow.
To achieve that, however, you have to basically ignore session variables (which may be a good idea anyway ;)) and the like and implement a framework that constantly tracks a users behavior, current location and any other related information. There's obviously a lot of overhead involved but that's the only way I know of to ensure that a certain user will always end up where you desire them to end up when they log in from different browsers, machines, etc.

Session sometimes timesout too quick

I am noticing session timeouts on my asp.net mvc web app randomly without browser being incative for for more than few minutes.
My understanding is the default timeout should be 20mins. But sometimes I get a timeout in couple minutes or even less than that. For example after browsing on the site for a while I might get a session timeout when i refresh a page very soon after I enter the page.
This is very random but I have seen this happen quite a few times now and I am not sure how I can trace this to see why I loose sessions every once in a while whithout browser being inactive long.
I checked my web.config an no timeout value is defined there so I assume it should be 20mins.
Hard to debug as this does not occur regularly..

There's an IIS setting for timeout. check it also
Maybe your application calls session abandon?
You can register session end handler to write to log on the server, to see exactly when this happens.

IIS overrides your web.config.
Go into IIS (this is for IIS 6)
Right click your website, properties, asp.net tab.
Click Edit Configurtation button on bottom, ASP.Net Configuration Settings, State Management, set your timeout here.

Are you creating any files in the bin folder, that can also cause the application to restart.
There are a number of other causes too, try googling .....
causes for asp.net web application to restart
I got a couple of hits that list the possible causes.

Continuous Deployment with an ASP.NET website?

I have a website in C#/ASP.NET that is currently in development. When we are in production, I would like to do releases frequently over the course of the day, as we fix bugs and add features (like this: http://toni.org/2010/05/19/in-praise-of-continuous-deployment-the-wordpress-com-story/).
If you upload a new version of the site or even change a single file, it kicks out the users that are currently logged in and makes them start over any forms and such. Is there a secret to being able to do deployments without interfering with users for .NET sites?

If you make a change to a config file, the contents of a bin folder of the app, or things like that, the ASP.NET worker process restarts along with your application.
This results in deleted sessions and kicked-out users.
The solution is to use other session storage methods other than the default InProc.
You can achieve this by setting the session state mode. The SqlServer and StateServer options provide very good remedy for your issue.
SqlServer mode is relatively easy to set up and get up and running. (Basically, it's just creating a database, running aspnet_regsql, and then specifying it to the config.) If you don't have MS SQL Server or don't want to use it, you can use StateServer, or create your own provider and use the Custom mode.
The only restriction is that you can only store serializable values with SqlServer and StateServer mode.

The reason you're seeing this is because you are resetting the application pool, thus resetting everyone's session.
The cleanest route would be to offload your session to a session state server, or minimize your use of session.
One way around this is if you can't offload your session is to always deploy to a new virtual directory. Your public facing URL then just redirects to your latest version. All users that are already logged in would continue to use the older version, but any new users would use the new version.

There are two alternatives to achieve that:
Do not use Session at all. (You may use cookies for authentication)
Use another Session-state mode. State server or SQLServer. http://msdn.microsoft.com/en-us/library/ms178586(v=VS.80).aspx
Either way you will also gain the flexibility to be able to run your application on multiple servers for performance or fail safe clustering.

Depending on what you store in the Session object, you may be able to reconstruct it in Global.asax's Session_Start handler. I used to do this in an internal application where we only really stored the user's identity in the Session, so we could just use their authorization cookie to recreate the session.
One thing to keep in mind if you do this: say a user loads up a form and then leaves for lunch, and you update that page while they are away. If they return to their desk and submit the form they'll be submitting the old version of the form to the new code-behind.

I suppose users are kicked because web-server application process is restarted. By default user sessions are stored in memory and session data is killed. Session provider is configurable option in web.config. May be choosing external (out-of-web-application-process) session provider is a step toward what you are expecting.