When one user login my site, this user have a session[sessionid like:xxxx-xxxx-xxxx-xx], when he login again elsewhere, he have a different session[sessionid like:yyyy-yyyy-yy-yyy], HOW CAN I DESTROPY THE PREVIOUS SESSION[sessionid like:xxxx-xxxx-xxxx-xx],after he login again with session[sessionid like:yyyy-yyyy-yy-yyy].
Destroy one session in another sesson!
Is this possible?
Thanks a lot!
There seems to be a lot of confusion regarding this request. I believe this individual wants to know how to prevent concurrent user sessions.
The proposed method: When a user logs in successfully, make this new user sessions active and abandon any other existing active sessions for the user.
My solution:
Upon Login, save the SessionID to a database, referenced to the user's account
In the Site Master file (or any file you may share with all the pages of your site), compare the current SessionID (HttpContext.Current.Session.SessionID) with the Saved SessionID.
If the two do not match, Abandon the session (Session.Abandon).
It's a simple solution, but it should address the issue.
don't worry about that, if you should worry it means your app design is bad.
put a logger in the Global.asax in the Session_End event and you will be able to track when unused sessions are closed by reading the log file.
Related
I am working on a small web application right now and part of the requirements is to allow the user to pick how their session will be managed: with either cookies or HttpSessionState. I have researched how to use cookies (http://www.codeproject.com/Articles/31914/Beginner-s-Guide-To-ASP-NET-Cookies) and Sessions (http://msdn.microsoft.com/en-us/library/ms178581(v=vs.100).aspx). I will be using non-persistent cookies.
The application will collect some data about the user (name, age, school) and take this session data and display messages on another page depending on the data that the user entered.
The thing I am having problems with is how to deal with how the user will pick the management. That information is also part of the session! The selection will be checked on every page on the web application.
I have researched globals (http://www.dotnetperls.com/global-variables-aspnet) but that is not a good method because it can be shared among different users which is not what I want! Correct me if I am wrong. How can I store this data temporarily through the session without actually using a session or a cookie?
Is it even possible to do this with cookies and sessions being mutually exclusive?
At the end of the day, you should save it somewhere. This option if it is not persistent, as it may be asked/changed by every time user visits the web site, the easiest way is to save it in a hidden html field. As user submits the forms, the value will be passed to the next page if you are using html forms. Or you can retrieve the value and send it manually in asp.net (e.g. Transfer).
You may use ViewState (not recommended) as well. If the information should be persister for future, try using User Profiles in ASP.net and save it as a custom field in database. This one is really cumbersome.
I've recently been developing a website using asp.net webforms that uses in proc sessions and I noticed that session ids are shared amongst browser tabs. So I was wondering what you would do for the following situations:
Problem:
Multiple logins with different users in the one browser problem
User opens browser tab 1, logins
with "user1" - store in
session
User opens browser tab 2, logins with "user2" - store in session
At this stage session information is now pointing to "user2" because of how session id is shared amongst browser
tabs
User tries an action on tab 1 and suddenly they have "user2"
information
How do you alert the user in tab 1 that the user has changed or how do force tab1 user to logout?
My initial thought was to keep a list of active users with session id via database or application object, but the problem I face is that in tab 1 what am I going to compare the list against, when I do a request the HttpContext.Current.User would be updated with "user2" how do I know browser tab 1 was initially for "user1"
Appreciate anyone letting me know of any alternatives or best practices for the above problem
Regards DotnetShadow
Why don't you warn when user2 logs in instead? With a message like "You are already logged in as user1, are you sure you want to login again as another user?"
All tabs in a browser belong to the same instance, so all tabs share cookies and sessions, there isnt much you can do about it. If you want to implement this badly the only solution that comes to mind is carrying a unique session id with each URL. Based on that unique id you can link a specific user. You will need customize the session logic and would have to make sure all links in your website carry this unique id. It could be done with alot of effort but the real question is , is it worth doing?
Some have suggested adding uniquifiers into the URL, and tracking based on those.
If you're going to do this, you may as well just let ASP.Net do this for you by turning on cookieless sessions - it then uses the URL to contain the session ID.
That's just how it is. You can't do much about it. Users are now accustomed to this behavior as it is consistent among famous internet sites like gmail, etc... so it shouldn't be much of a problem to them.
What I do to avoid this problem is redirect to append a short, random in-url login-identifier.
Then, rather than use session directly, I store a strongly typed object in the session vars under the random in-url code, and use that object for session storage. If you want to keep it simple, you could use a Dictionary. In addition to the normal session timeout, you should keep track of the last usage within each login-id and manually time-out a session if it's too old to avoid new users from keeping old logins alive.
Essentially then, each ASP.NET session corresponds to any number of login sessions.
This has the following advantages:
You can log in as multiple users simultaneously. That's handy to be able to do for many sites.
In public terminals, it helps avoid accidental session hijacking. When a user leaves a public terminal, closes the webapp tab but not the browser (which is quite common) and another person then approaches that terminal and opens a new window or tab to your site, this new user sees no trace of the previously logged in user. Of course, users should log out, and anyone can inspect the history, but there's no reason to invite abuse.
CSRF attacks against your site are a little bit harder since a url without the random login-id is meaningless.
The implemenation is quite simple if you use a hashtable - after all, any sessionstate-consumer already is written to store and retrieve data from a hashtable, you just need to change the hashtable it's using and should ideally include a custom timeout.
The obvious downside is that you need to include the random code in the url; and that you need a bit of extra implementation. You might hide the extra code using an iframe and/or javascript+XHR based site, but doing so is a much more invasive change to a site. Finally, note that cookieless sessions are not the same; though they're simpler to turn on, they involve a much longer less human-friendly url token, and by lacking the normal cookie session token, also are less secure vs. session hijacking (since suddenly any other program or even machine that discovers the session ID can pretend to be that user).
How about storing the data in viewstate? That would be unique to every window.
The Setup:
Account controller with the typical logon / logoff stuff that comes baked in from the template. Not much modification here on the logon page. Using a custom membership provider (SQL), but I don't think that is impacting what I am trying to do here.
The Requirements:
The client wants to handle licensing by limiting concurrent users and not by total users. So, after referencing this post here, I set out to make this work for what I need to do. And that is to track maximum and current users for each organization that has signed up for our application. No problem, just have an application("max") and application ("current") which are both hashtables with the key being the organization id and the value being current or max users for the organization. On Session_Start, I would increment the current users, check if it exceeds max and either a) redirect to an error page or b) let them go on with what they need to do. On Session_End, I would decrement the count.
The Problem:
When using formsService.signIn, what is actually stored in session? I cannot seem to gather any information about my session in the session_start except for the session ID. So, I cannot increment the correct number for user tracking. And I cannot add a variable to session as session_start will have already fired before I get the opportunity.
The notion that session is somehow connected with authentication is a myth. They are entirely independent of each other. Session can even be shared between multiple users if they happen to share their session key; that's why you never put security-sensitive info in session. Session can also expire while you're logged in. Likewise, your session is still active after logout unless you explicitly abandon it.
Session is more like a user-specific cache.
So you need to accept this fact and adapt to it. Look and see if the current user is authenticated during session start. You'll need to increment during logon as well, since the session will have already started. Etc.
In our application, we have a need for a user to "impersonate" a different user. Think of it as a hierarchy -- Bob is above Frank in a hierarchy. Bob is logged in, and he needs to do things in the system for a short time as Frank. So, we have given Bob a list of users that report to him, and an impersonate link. He clicks on this link, and, behind the scenes, I log Bob out, and log in as Frank. I also set a session variable that tells me that really Bob is they guy who is the user. Also, Bob (acting as Frank now) has a nice little link at the top of every page that says "Stop Impersonation."
In addition, when Bob is impersonating Frank, Bob is restricted from doing some things, like changing Frank's password.
This was working great, until we encountered a situation where, if the session (I think -- getting confused here) gets destroyed (such as when I copy up new code and dlls to the live site), then when Bob clicks on "Stop Impersonation" he gets redirected to the default page, and is still logged in as Frank, but without the Impersonation session variable. So, now Bob really is logged in as Frank, and can change Frank's password (among other things).
How is it that a session variable (Impersonation) gets destroyed, but I guess the session is still hanging around, because it doesn't make the user log in again?
This is a somewhat serious bug for how our system works (bug in our code, I'm sure, not in .Net). Does anyone have any suggestions for a solution for this?
We are using ASP.Net c#, aspnet membership services, .net 3.5, forms auth...not sure what else you need to know.
EDIT: Updated information. Looks like when "something" happens, for instance, when I recompile some dlls and copy them to the webserver, the session gets dumped. Or, rather, the variables in the session get dumped. The session id stays the same. I do get to check for Session.IsNewSession and it returns true, even though the id is the same as it was before.
Just like Utaal mentioned, Membership Services is separate from Session, so it's forms auth token is still hanging around in the browser, but my session variable telling me that that isn't really the user who is controlling the browser isn't there anymore.
EDIT: Sky, here is what I'm doing to authenticate a user. I can't figure out where I would insert a ticket into this flow:
if (Membership.ValidateUser(txtUserName.Text, txtPassword.Text))
FormsAuthentication.SetAuthCookie(txtUserName.Text, false);
So, where can I slip in a ticket object and set my own information?
Matt,
Use the UserData slot on the forms ticket to store the impersonation information. That is what it is for.
Then your info will not get lost with the session.
If you would like a simple example of creating your own ticket, amongst other things, check this. You may want to focus on the login page and the tickethelper class.
I think your problem is due to the fact that Forms Authentication and Session are two different things and are not interconnected: both of them (usually) use cookies but Forms Authentication stores the encrypted logged-in user directly in the cookie while Session stores information in-process (even if you can change this behaviour) and uses a cookie with a session identifier to retrieve it.
So, when your session information gets lost (or session expires) it isn't really still hanging around (except for the invalid session cookie on the user's pc). On the other hand the Forms Authentication cookie is still valid (ASP.NET decrypts it and authenticates the user for the request).
A possible solution is to detect the creation of a new session (using HttpSessionState.IsNewSession MSDN) and sign out the user (using FormsAuthentication). You can then redirect user to login page.
I am trying to find out in my asp.net application the users that are currently logged in the application by searching on the session info. Currently, I am only able to see my current session, but I cannot find out if there are other users using it. Is there a way to see if there are other users using the application by looking at the session information
Session state is per user - Application state (global) seems to be what you're looking for.
There are 2 hashes Session and Application, in which you can store key-value pairs.
A way to do it would be to update Application[UserNamesList] whenever there is a successful login. This would then be visible to all users. Application state would however be lost whenever the App Web Server recycles or restarts... but that shouldn't be a problem in this case.
A session is supposed to only give you information about the currently logged-in user.
If you need to keep track of all logged-in users, you could consider writing the users into a global variable. Here is info on how that works. Note that sessions expire. You would have to write, for each user, the time the user was last seen (i.e. each time they hit a new page, update their record). When the time they were last seen is greater than your session timeout, it's safe to assume they are no longer logged in and you can remove them from the list of current users. If they just up and close their browser, you will not be alerted and you will still think they are logged in even though they are not.