限制访问 Web ASP .NET 应用程序的用户数量
如何限制 Web 应用程序的用户数量。
您可能希望将 Web 应用程序限制为一次仅处理 20 个用户。 我们公司销售基于多个许可证的应用程序，但我们不确定网络应用程序中的行为是什么。
我看到一些建议说，当用户登录时，您可以将用户帐户标记为“LoggedIn = True”。然后，每次新的成功登录尝试都会检查“LoggedIn = True”记录的数量。 如果超过限制，则该用户将被拒绝。
在这种情况下如何处理意外输入？ 如果：
- 用户没有点击注销，并关闭浏览器
- 浏览器崩溃，用户没有机会注销
- 网络连接中断，客户端断电等等。
以上所有情况仍然会出现“LoggedIn = True”标志设置并影响登录用户的数量。 这可能会无意中阻止真正的经过身份验证的用户。
如果可能的话，我正在寻找更多 ASP.NET 解决方案。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
假设您的用户身份验证在某种程度上是基于会话的，那么所有“意外”情况（这实际上是常态 - 人们似乎很少注销 Web 应用程序）的答案将是，当会话超时时，这些用户插槽将变得空闲。 因此，您需要调查应用程序的使用模式。 如果很多人登录几分钟，但不超过这个时间，那么 30 分钟的会话超时将意味着很少有人真正使用该应用程序。
根本问题是 Web 应用程序本质上是断开连接的，因此您无法监视用户在页面请求之间实际执行的操作。 通常，您会向特定用户出售此类应用程序的许可证（因此，如果一家公司购买 20 个许可证，就会为他们提供 20 个用户名和密码）。 然后，您当然可以通过拒绝第二次登录或停用前一次登录来防止使用相同的用户名和密码进行多次登录（这可能是更好的方法，以防有人真正从一台计算机转移到另一台计算机而没有注销其中之一）您概述的原因）。
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).
最常见的解决方案是使用活动计时器。 您可以假设活跃用户将在“X”时间内（例如 5 分钟左右）至少发出一个请求。
您可以通过放置一个由页面加载时启动的计时器触发的 ajax 样式异步请求来强制执行此操作。 例如，如果您假设所有活跃用户每 5 分钟至少发出 1 个请求，则每个页面将每 4 请求一个空（但无缓存）页面强>分钟。 这样，只要他们打开浏览器窗口，您就始终可以看到该用户的活动。 同样，这是由异步请求处理的，而不是由任何类型的重新加载指令处理。 这使得它对用户绝对透明。
作为额外的好处，看看您是否可以使该 ajax 请求提取一些有用的信息，而不仅仅是强制执行许可限制。
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.
正如 David 指出的，主要问题是区分空闲用户和已离开应用程序的用户。
一种可能的解决方案是保持较低的会话超时（例如 1 或 2 分钟）并使用回调函数来保持空闲用户的会话处于活动状态。 然后，您可以增加 Session_Start 中的计数器并减少 Session_End 中的计数器，并使用它来跟踪活动会话的数量。 如果活动会话的数量超出您的限制，您会将新用户重定向到放弃会话的页面，并告诉用户您目前的访问者太多。
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.