I've made an asp.net site, which uses Session objects to store information for each logged in user. To check if a user is still logged in, I check if a certain object exists in the Session.
The system used Jasig CAS authentication, and the single sign on part works (as in: after the log in, the Session object of the user is set up correctly).
CAS also supports single sign out. The way this happens is that CAS calls a url on my site, with some parameters about the CAS session.
What I need to do now, is invalidate all Session objects for the specified user.
How can I, from a page on my site, invalid the Session object of a random other user? Is there a db I can clear, is it all in memory (I can look at web.config if I know what to look for)?
I've seen this question asked before, and most answers are "keep a global variable next to the Session global variable, and check that one too to see if the user should be logged out or not", but I don't like that solution...
Cheers!
The session is by design private to individual users. Therefore to abandon it, it has to be done by the user.
So you might have to use another a list & check that.
Ideally though, you shouldn't tie your authentication state to the session. Whether the user is authenticated or not should be independent. You can then choose to abandon the session by querying the authentication state. It also makes it easier to implement mechanisms like counting logged in users & ensuring login from only 1 location - should you require these.
Related
We have a log-in form in ASP.Net Webforms. and when user logs in we save the user id to session state.
Session["CurrentUserId"] = user.Id;
So this is how we know a user is logged in.
if(Session["CurrentUserId"] == null) Redirect("Login.aspx");
This is all we use Session for. I am storing session in DynamoDB because we have many load balanced servers. But sometimes DynamoDB gets overloaded or gives errors. So I trying to get rid of session state to avoid these errors and to simplify a login process.
So what alternatives are there? How do modern websites log people in and remember they are logged in, and timeout after x minutes?
Is there a way to use a secure cookie to just do it? And how would you expire it if user doesnt do anything for 20 minutes? It has to work over a collection of web servers.
Storing user ID in session is not necessarily bad but has to be combined with other things in order to secure the site against things like session fixation attack and CSRF (also known as "session riding"). It is also problematic in a web farm if you are using in-proc session state.
In ASP.NET web forms, the standard way to authenticate is to use forms authentication, which places an encrypted cookie ("authentication ticket") on the browser. You may also want to put the user ID somewhere in session and compare it to the authentication ticket in order to ensure they match.
if you using the standard FBA login providers?
You can get user logon ID with this:
Membership.GetUser.ProviderUserKey
And you can get user email with this:
Membership.GetUser.Email
So, the user logon id can be fetched with above.
As for session() being a bottle neck?
Well, it not all that bad - you not "updating" the session() value by doing this, so it certainly does not have to be written back each time (for a post) and also it means that a lock on session() during post backs etc. should not occur.
I would however consider one of the above two approaches, since then session() re-sets or anything else would not matter to get the user ID, or email.
As noted, this much depends on what security and authentication provider you are using here.
I was revising the concept of Session Objects in JSP & ASP.Net.
I was confused, 'when an actual Session Object is created?'
Until recently I thought it was created when a user logs into his account, But now I read in the books that its implicitly created when the user visits any page on your site.
So when is it actually created? And are JSP sessions different from Website User Account sessions?
If the latter is correct, Is a second new Session created when a user actually logs into his account, and the previous session destroyed?
eg: A shopping site may allow a user to select many items & 'Add to My Cart'. What happens to this data after he logs in. Is a new session created internally after destroying the initial one?
If this seems confusing, then you can just specify how Session is typically implemented in real-world systems (as I'm a student)? When is the session typically started? What data is stored in it? What is the typical timeout you set and why?
My research: JSP sessions are abstract concepts and User account sessions are implementation specific. Both are different
A session is typically implemented by
generating a unique token,
creating a Session object to hold session data and store it in a map, indexed by the unique token,
sending a session cookie containing this token to the browser.
Each time a request comes in from this browser, it contains the cookie, and the container can thus retrieved the appropriate session from its internal map of sessions.
So yes, a session can exist before a user is authenticated, or even without authentication at all. And when a user is authenticated, he keeps the same session. The only difference is that you typically add the user ID in the session, in order to associate the user with the session.
You could thus, for example, let aninymous users shopping and add items to their cart in the session, and only ask them to authenticate once they need to pay (to retrieve their stored account). Or you could let them add items to their cart, and never authenticate them at all.
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.
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.
I am developing my login for my new homepage.
Now I found out, that I must save something like the userID (or another value that i can recognize my user) in the session variable of the browser.
At the moment I use INT for the userID.
So isn't it unsafe to put the userID in the session?
E.g. when I edit my session variable manual from userID 111 to userID 112, than I am logged in as a complete other user?!
Yes, it is unsafe to rely only on user ID.
You may wish to add a unique authentication token generated and remembered by the server. Also a very simple solution, but it will stop manipulating the user ID since the correct value for authentication token for the other user cannot be guessed.
You also need to submit both user ID and the corresponding authentication token at each request to be jointly validated on the server side, prior to performing the requested operation.
P.S. The above applies if you store this information in cookies which are accessible on the client side and can be manipulated. The viewstate (serialized in pages) can also be manipulated. The session collection is a server-side variable that is not available on the client so it cannot be manipulated. In this later case your user ID should be safe.
I would recommend you to implement the dual system: store the user ID and the token both in cookies and in the session and use the same validation logic (for simplicity). Should cookies be disabled you automatically fallback to using the session without changing your code.
The session variable is not stored in the browser, it is stored on the web server. (Typically anyway.)
A token indicating which session variable to use, is stored in the browser.
So storing the userid in the session variable is fine, as the user has no access to this directly.
If the user were to change the session token, to another one, that would be a problem, but they'd need to know the other token first. (I'm not sure how to do that myself.).
(You can further diminish this by using encryption, or other identifies like IPAddresses etc, it's really a case of how secure do you need your website to be?).
Also, if your site needs the user to log in, it's advisable to use https/SSL.
As Bravax says, the user does not have access to the Session variables (Cookies they do have access to).
If you are worried at all I would use a GUID instead as they are not sequential and nearly impossible to guess.
Also, have you looked at the built in stuff in .Net for authentication? Look at FormsAuthentication.
HTH,
Arry