How do I limit the number of users to a web application.
You may want to limit the web app to only handle say 20 users at a time. Our company sells applications based on a number of licenses, but we are not sure what the behaviour could be in a web app.
I have seen some suggestions saying you can flag a user account as "LoggedIn = True" when a user has logged in. Then each new successful login attempt checks the number of "LoggedIn = True" records. If it exceeds the limit, then the user is rejected.
How will unexpected input be handled in this case? What if:
The user doesn't click logout, and closes the browser
The browser crashes, and the user does not get a chance to do logout
Network connection breaks, electricity on the client goes off etc etc.
All the above will still have the "LoggedIn = True" flag set and contribute to the number of logged in users. This may unintentionally block out genuine authenticated users.
I am looking more for ASP.NET solutions if possible.
Assuming your user authentication is somehow session based, then the answer to all your "unexpected" cases (which will actually be the norm - people rarely seem to log out of web applications) will be that those user slots become free when the session times out. So you'd need to investigate usage patterns of your application. If you get a lot of people logging on for a couple of minutes, but no more than that, then a 30 minute session time out would mean very few people actually get to use the application.
The fundamental problem is that web applications are inherently disconnected, so you can't monitor what a user is actually doing between requests for a page. Normally, you'd sell licences for such an application for specific users (so if a company buys 20 licences, that would give them 20 user names and passwords). Then you could certainly prevent multiple logons by the same user name and password, by either refusing the second logon or deactivating the previous one (which is probably the better approach in case someone has genuinely moved from one machine to another without logging off for one of the reasons you outline).
The most common solution is to have an activity timer. You can assume that an active user will make at least one request within "X" amount of time -- say 5 minutes or so.
You can enforce this by putting an ajax-style async request triggered off a timer that starts when the page loads. For example, if your'e assuming that all active users will make at least 1 request every 5 minutes, then each page will request an empty (but no-cache) page every 4 minutes. That way, as long as they have the browser window open, you'll always have activity from that user. Again, this is handled by asynchronous requests, not by any sort of reload directive. This makes it absolutely transparent to the user.
As an added bonus, see if you can make that ajax request pull down some useful information, rather than just enforcing licensing limitations.
As David points out the main problem is to differentiate between idle users and users that have left your application.
A possible solution would be to keep a low session timeout (say 1 or 2 minutes) and using a callback function to keep the session alive for idle users. Then you could increment a counter in Session_Start and decrement it in Session_End and use it to keep track of the number of active sessions. If the number of active sessions goes beyond your limit you would redirect the new user to a page that abandons the session and tells the user that you have too many visitors at the moment.
Related
I'm the new here.
I've a problem like this: I create a Register page in ASP.NET (C#) which allow to guest can register an account at my site. All user must active their account before using my website, if after 15 minutes, user doesn't active account by mail => delete that user from database, my problem is how to do it automatically?
Rather than using a timer to remove a user, I would use a more conventional approach of having an expiration time for the user (or perhaps their password). That is, when they first register, assign an expiration for 15 minutes after the present time (e.g. in a column ExpirationDate in the user table). In your authentication process, the logic should validate that the user's ID has not expired.
The problem with using a timer is that many things can go wrong. For example, if your application restarts, any active timers will be lost. It's very brittle. It's also kind of using a hammer to kill a fly. It's not necessary to ensure that someone's user record is removed immediately from the database after 15 minutes. It's only necessary to make sure they can't authenticate after that time. So make the design match the business purpose in the easiest possible way. If you really want to delete records (rather than, say, give them a chance to try again after resetting a password or something) then you can do this with some external maintenance process.
How to tackle this session problem in ASP.NET,VB.NET?
The following requirement are there:
When the authorized user logs into the system that user is not allowed to login from another computer or in different browser other than that user is using right at this time.
The remedy we applied was: We have kept "Is_Loggedin" as a column with data type "bit" in a mst_vendor as a table name. When a user logs in we set the flag, Is_Loggedin, to "1" and each time when someone tries to log in using this account, the system is showing the error "The user is already logged in.".
When the user logs out it turns to "0" as the logout procedure calls as soon as the user clicks the log out button.
Problem scenario:
When the user closes the browser the flag remains the same, that is, "1".
When power gets off, it remains the same as "1".
If the session timeouts after a predefined value it remains the same.
There may be different scenarios other than this.
Is there any way so that we can store this internal flagging for the user's login status using the application object?
It may improve efficiency of the system and also eliminates the above problematic scenarios.
You should use the Global.asax file and use the Session_End function.
Session_End: Fired when a user's session times out, ends, or they leave the application Web site.
Store a datetime as another column next to the bit, and update it each and every time the user requests a page.
When a new user comes along with the same credentials and the bit is "1" you can check the datetime, and if it was a while ago you can be certain the user is no longer there. So let the login go ahead.
You could keep a pulse going in script, and when the pulse times out, consider the user finished with that session.
The benefit to this is that you can tell the difference between the user sitting idle on the site and the user leaving the site.
From a very top level view, here is what you can do
Use Cache with SlidingExpiration.
Everytime a user attempts login, check the cache with his username as the key. If an entry exists in the cache, you can say that user is already logged in and deny login.
If the key is not found, allow login and create a new key in the cache as the username and set the sliding expiration time. (This should be carefully chosen as this would be the duration, the user wouldnt be locked out after the browser is closed and user attempts to relogin.)
In the Application_PreRequestHandlerExecute handler in Global, check if the user is currently active (you can use sessions for this), reset the sliding expiration time for the user. This way, with each page request the cache expiration time would be reset.
If the user closes the browser and moves off, the cache would expire after the set period of time, and would free the user to log in again.
if in case the user attempts to login again before the cache expires, the user would have to wait for some time to let the cache expire.
if the user logs off properly, you can remove the cache entry on the logoff event such that user doesnt have to wait to relogin.
The Sliding expiration timeout can be synced with session timeout to emulate the actual session timeout for the application.
With this approach, you would also save on a lot of database round trips to update/check the user status and this would work irrespective of the hosting enviornment or the session modes.
Yeah, a script would be a good idea. Just set the session timeout to be 5 minutes instead of 20 and then write a method into session.end in the global.asax file that updates the database accordingly.
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.
How do i keep checking if a user still is active, for like every 1 minute? I need to know which user is currently active and who is not! I'm not using ASP.NET membership provider!
Lets say, maximum 3 log in are allowed for one user to log in simultaneously from 3 different locations, if the same user, which is the 4th log in, try to log in from another location again, i would like to block the 4th log in.
I have few issues regarding this as well! If the user unplug the connection cable or close the browser, how do i figure out if the user is still active?
I would need more detail about exactly what you are trying to accomplish, as you have asked a fairly vague question. However, I would think the best way to determine if a user is active is to check if their ASP.NET session is still alive. There is no "accurate" way to test if a user is still browsing your site, because they could be sitting there reading, or be AFK, or be in another program on their computer...dozens, if not hundreds of scenarios could exist on the client side.
However, the user's ASP.NET session will only live for a specific period of time between each activity from the user (GET, POST, etc.) Usually after 20 minutes, ASP.NET will clean up the users session, and when it does, it will fire a Session_End event that can be handled either in Global.asax, or with a custom HttpModule. You would then be able to flag that user as inactive in your own database, send an email, or do whatever it is you need to do.
You can use the HttpResponse.IsClientConnected property to check if the user is still conncted to the session. For details see this -->
http://msdn.microsoft.com/en-us/library/system.web.httpresponse.isclientconnected.aspx
Alternatevely, you can set a counter at Session_OnState at global.asax to check for the active session available and do your stuff based on that.