共用方式為

HOWTO: See who is logged into IIS

  • 發行項

This is a common requested "feature" of IIS - I want to see what users are currently "Logged in" to my IIS application. Now, this feature can certainly be implemented, but it is unlikely to ever be a built-in "feature" of IIS, and here is why...

Question:

Is there a way/tool to see who is logged into a website under IIS 6??

Answer:

There is no built-in mechanism in any version of IIS to see who is "logged into a website". However, the feature can definitely be custom implemented, depending on what "logged into" means for your application.

The reason why there is no built-in mechanism in IIS to do this is simple - web servers like IIS implement the HTTP protocol to process requests and serve responses, and HTTP simply has no concept of "logged into". HTTP is stateless, meaning that the web server does not remember anything from one request to affect a subsequent request, but "logged into" implies that some request "logs in", some request "logs out", and some number of request(s) in between which is consider "logged in". Thus, "logged into" implies maintaining some sort of state for a sequence of requests, privately maintained outside of HTTP, so IIS as an HTTP web server has no idea how to show privately maintained state to you. This pretty much means that this feature will not be built-in to IIS.

In other words, the idea of "logged into" is actually an application-layer concept, much like "session state", so this means that to "see who is logged into a website" you must write custom code to:

  1. Determine what "authenticated user" and "logged into" means
  2. Interact with your particular application-layer framework to determine the status of data for #1 and record it somewhere outside of the application
  3. Write another application to display the data recorded from #2

The reason that you must record this status outside of the original application is security. No secure application-layer framework will allow a child application to query/interact with the state of any other application for obvious security reasons, so there is no way you can write a web application that queries the application-layer framework for all logged in users running applications and display it. Thus, the best you can do is to have each application independently record its status somewhere else for aggregation, which you can later data-mine. When you step outside of the system, we presume you know what you are doing security-wise.

I can think of two basic approaches for gathering the "authenticated user" and "logged into" data:

  • Modify all your web applications to record the "authenticated user" as well as "logged into" status on every single page interaction to some external database and then data-mine it
  • Write an ISAPI Filter which captures the "authenticated user" as well as "logged into" status on every single request and logs it to some external database and later data-mine it

Now, some of you may balk at having to modify all your web applications to support this sort of monitoring, but sorry, you are barking up the wrong tree here. Remember, IIS has nothing to do with what "logged in" means - your application framework determines this, usually in the form of session state that records whether someone is logged in or not, and it is usually trivial within each application to determine "authenticated user" and "logged into" status and record it.

So, why not go the ISAPI Filter route which requires no modification of web applications? Well, the problem here is that ISAPI Filter operates at the HTTP-level, like IIS, so it has no idea about application-level concepts like "session state" or "logged in", and if your application does not use standard authentication protocols that IIS supports (i.e. you use forms-based authentication), then it has no idea about "authenticated user", either (if you use the standard authentication protocols, then ISAPI Filter can look up the "AUTH_USER" to determine the name of the "authenticated user").

For example, suppose your application framework uses cookise to maintain session state, which maintains what "logged in" means, and you use custom forms-based authentication within the application framework, which also uses cookies to store an encryped form of the user credentials, then all ISAPI (and IIS) sees is a bunch of anonymous requests with a certain cookie containing session ID and some encrypted blob of data being passed around. The session state is unknown as far as ISAPI is concerned, along with the values of "logged in" and "authenticated user". Basically, the only way this can work is if you reverse engineer how the application framework implements session state and have the ISAPI Filter read from arbitrary locations in memory, but that is very dangerous and not recommended.

Now, there are companies out there that have written ISAPI Filters and spent a lot of time reverse engineering various application frameworks so that they can use the cookie value to link requests together as belonging to a certain "session", and maybe even reverse-engineer the name of the custom-authenticated user. But this is definitely fragile stuff and cost money, and IIS can do nothing about it. You are talking about arbitrary implementations of application frameworks outside of IIS control.

Bottom line is that no web server can provide this feature. But, you can definitely write extension modules on top of the web server to work for certain application frameworks. And some people may charge for these modules, other may not.

//David