Reputation: 43
Excuse me for my poor english.
It's possible get all thread requests from an ASP.NET application? I don't need execute the complete logout of current user if in same time another clients are authenticated with this same username. Perhaps I could query another request threads for know if I need do that.
I will try simplify the question... Can I know all actives requests from ASP.NET application in a IIS server on C# code? Now I try get the threads of WebDev.WebServer40.EXE process, but don't seems the requests threads.
Upvotes: 0
Views: 744
Reputation: 43
I did look different possibilities. The best option perhaps is use the System.Web.Administration dll and WorkerProcess.GetRequests method. The main problem is that dll only works with IIS7 version o superiors. Exists some way for get something similar in IIS6? For me the most important is get the current request theads managed by server and know the credentials of each thread and internal info.
Upvotes: 0
Reputation: 15076
I think you are approaching this wrong. You cannot log out a user in the middle of a session since http is stateless and the users credentials are always sent as part of the request, be it a cookie, a Bearer token or some value in the Authorization
header.
Performing a logout as part of a single request is therefore not really feasible.
To me it sounds like you want to unauthorize the user without necessarily unauthenticating the user. That is, the user id is still connected to the request, but you no longer want to grant the user access to whatever resource, that was available to the user a moment ago.
This decision is made at a unique point in time, so all requests concurrently with the time you made the decision that the user is now unauthorized will behave differently depending on whether the authorization was checked before or after the unauthorization. New requests are sure to be denied though.
A http request should not take longer than milli seconds or sometimes seconds. Are any ressource you are protecting so important that it cannot live with this inconsistency window, you probably shouldn't expose it via http.
But if you want to make this rather (and perhaps unnecessarily) complex mechanism to unauthorize already authorized request, you should make it as a http handler executing as the last part of the aspx pipeline. It should look at the user id and some kind of shared blacklist maintained by the authorization system.
I think you should live with the inconsistency though. But be sure to separate authentication (who) from authorization (what the user can do).
Upvotes: 1