0

I wanted to try this code/solution to my ASP.net (VScode 1.69.1) but I am not sure where is the "Global.asax". Anyone know how I can apply the code below to asp.net core?

https://teknohippy.net/2008/08/21/stopping-aspnet-concurrent-logins/

sellavsert
  • 27
  • 4
  • That's WebForms, which is dead, obsolete, and should not be used by anyone - and VS Code doesn't support WebForms. Also, what's your problem with concurrent logins/sessions, exactly? – Dai Jul 19 '22 at 03:00
  • I need to restrict a user from logging in again when he/she already logged in using a different browser. – sellavsert Jul 19 '22 at 03:07
  • Careful @Dai while I agree to a certain extent, WebForms is far from _dead_ and still serves a purpose. In fact MS are investing right now in a new design experience for web forms. While you and I have evolved, there is a need in market for WYSIWYG editors, and Web Forms excells in this department. OP's request is therefor valid and we can help, we should not be degrading our fellow developers, we are here to help. – Chris Schaller Jul 19 '22 at 03:10
  • @ChrisSchaller WebForms was never WYSIWYG though: the design pane would always show error messages or corrupted layouts as soon as you do something non-trivial - and remains frozen-in-time with IE7-era capabilities - and even if the designer did work reliably, the web is fundamentally incompatible with WYSIWYG designer tools: it's impossible to _express_ a CSS `grid` or `flex` design using point-and-click tools - and of course, by the time someone _groks_ modern CSS layout they'll already prefer writing CSS by hand instead of using a flakey designer tool. – Dai Jul 19 '22 at 03:24
  • if web forms is dead, then why are they spending boatload of money, and now adopting the new chrome render engine to work with web forms and live preview? See this article:https://devblogs.microsoft.com/visualstudio/design-your-web-forms-apps-with-web-live-preview-in-visual-studio-2022/ ----- so while webforms is legacy, they actually adopted live preview, and have adopted the new chrome engine - as a result, your forms designer now has even much better rendering then it ever had. So webforms is legacy, but there is a boatload of existing applications we have to support. – Albert D. Kallal Jul 19 '22 at 18:30

1 Answers1

2

I would not advise you to use that code, it wasn't even good advice back in 2015, but we can explore the concept and it's flaws which might help you come to a better overall solution.

This post will provide some context to the issue: Single Instance Login Implementation but is not a direct duplicate. The original source article does actually go into better detail about the general issues with this approach: http://www.nullskull.com/articles/20030418.asp

Using an In-Memory cache is not a viable option for production as multiple instances of the application would not share the same cache, especially if the application is hosted across multiple servers or serverless infrastructure that is configured to scale out beyond a single instance.

If all you want to do is block new logins, if the user is already logged in, then a server-based or cache concept itself is the right solution, conceptually to enforce a single instance across different browser sessions and across multiple servers will require that there is a server-side cache or store that holds the source of truth for all active connections. This could be in the form of a database or a distributed cache like REDIS.

But this is not a practical model for how users actually use their browsers and devices. Instead of blocking new logins, it is more practical from a user point of view to expire or force close the existing logins. The problem with only blocking new logins is that if the user doesn't have access to the original browser session that holds the login, then there is no way to log out the previous session, you would have to wait for it to timeout. The challenge with being able to expire a login session is that your clients and the server code must be designed to round-trip to the session store to validate the session token. Most default JWT or even cookie implementations do not do this, they will rely on the expiry or validity information in the token itself, and bypass consulting the store.

Instead of the article you have found, please try these resources:

Chris Schaller
  • 13,704
  • 3
  • 43
  • 81