History Tab - Glimpse/Glimpse GitHub Wiki

The History tab lets you select a historical or remote HTTP request for Glimpse to display diagnostics information for.

This tab allows you to view requests from not only your own browser, but from other devices in any location. This allows for several interesting use cases, including mobile debugging, remote client debugging, tracking workflows, etc.

1. Client Session Panel: List of available client session's
2. Client: Name given to the session that is being tracked by Glimpse
3. Count: Number of requests that are available to be viewed
4. View: Show requests from a client
5. Client Request Panel: List of available client request's
6. Request URL: URL that can be used identity individual requests
7. Method: HTTP method used for the individual request (typically GET or POST)
8. Status Code: Response status code for a HTTP Request
9. Duration: Duration time of a request in ms
10. Data/Time: When the request was made
11. Is Ajax: Whether the request was made via Ajax
12. View: Opens a given request as the current context

So your site works fine and is in production when you get a call from a user reporting a problem on a particular page. The same page works fine on your machine, but is buggy for them.

Glimpse has a feature which allows you to look at the "debug information" for page requests made by other users on other machines. This is also helpful if you are debugging a site in a mobile browser where the Glimpse client panel is not usable (i.e. a mobile device).

• First you need to make sure that Glimpse is installed on the production site and turned on
  • To do this, you will want to ensure that the Local Policy is disabled so that Glimpse can be accessed
• Next, you will want to flag their "session" as having Glimpse enabled in a read only capacity (meaning Glimpse will collect the information but they can't view it)
  • Typically this is done by setting a flag on their (perhaps in the user table or another like mechanism) and having a Custom Runtime Policy look for that flag
• Once setup, we can now ask the user to load the problematic page again and you will be able to track their movements through the site as they replicate the problem

When using the 'History' tab, you will note that the right hand side you should see a list of different clients and the number of request that were monitored by Glimpse. In the 'Client' column you should see the name that was specified by the user. Click on 'Inspect' next to it to show the requests for the client.

The History tab behaves similar to the Ajax tab, you can 'Inspect' one request to see the full data about that request. On the Request tab you can verify that the request was made by a History client machine. You can further review the information to find out what may have caused the problem.

It can also be helpful for local development. You can use different browsers to access your site and then compare the requests in one place.

• What happens when the maximum number of stored requests is reached (by default 25)?

  Internally we store the requests in a FIFO Queue. This means that when the maximum number spaces in the queue are filled, we take the first one that was entered and remove it from the queue, thus making room for the new request.

• How do I “enabled in a read only capacity” in Glimpse? Glimpse has a bunch of IRuntimePolicy implementations that come out-of-the-box and there are many more, third party or custom made.

Those IRuntimePolicy implementations determine how far Glimpse should go in monitoring requests or even completely ignore some or all of them based on some custom logic. Glimpse calls the RuntimePolicy Execute(IRuntimePolicyContext policyContext) method on all those IRuntimePolicy implementations at runtime.

Each IRuntimePolicy will then return a RuntimePolicy indicating whether Glimpse should continue to monitor the request or even to stop monitoring completely.

If you look at the RuntimePolicy values then you will see that it is a flags enumeration where each value is less restrictive than the previous one (except for the ExecuteResourceOnly value, which is a special case).

In your case you want to monitor, collect and persist data about requests made by users of your application and this in such a way that they don't see the Glimpse Client at the bottom of the page nor that they need to flag themselves. If you look at the RuntimePolicy than the value PersistResults is the upper value you want requests of your users to be assigned, while keeping in mind that an Off value might still be a valid value for one or more requests.

The question now is: How can you achieve this without user interaction?

Under normal circumstances you would set the Glimpse Control cookie which will satisfy the out-of-the-box Glimpse ControlCookiePolicy. If you are running in a production environment than most likely you have an additional IRuntimePolicy which makes sure only admins or super users are allowed to have that cookie set, otherwise anybody can set that cookie (that control cookie is not used for authorization) and get some sensitive data.

That said, you need an additional IRuntimePolicy now that checks whether the given request is eligible to be monitored but at the same time indicates that the data should only be persisted and not returned as part of the response. This check should then be based on something the identifies a session you want to monitor as mentioned in the documentation excerpt above. So if you would assign a user a DebugMySession role for instance than you could have a policy like this:

public RuntimePolicy Execute(IRuntimePolicyContext policyContext)
{
    var httpContext = policyContext.GetHttpContext();
    if (httpContext.User.IsInRole("DebugMySession"))
    {
        return RuntimePolicy.PersistResults; 
    }

    return RuntimePolicy.On;
}

Keep in mind that returning RuntimePolicy.On does not mean it will be on, it only means that this policy doesn't matter what the final outcome will be once all IRuntimePolicy implementations have been processed. This policy only wants to make sure that if that role has been assigned, the final outcome can never be less restrictive than PersistResults.

Applying the above also means that you will have to disable the ControlCookiePolicy in the configuration, otherwise the ControlCookiePolicy will return RuntimePolicy.Off as the cookie will not be there.

The same applies to your admin or super user check. So a better idea might be to combine the admin/super user role check with the debugging role check above, so that you have one policy returning the correct RuntimePolicy value.