Search code examples
glimpse

How do I "enabled in a read only capacity" in Glimpse?


I want to be able to view user sessions for debugging purposes. I am attempting to follow the setup instructions for the History tab located here. I am not clear how I enable glimpse in a read only capacity, and my google-fu is failing me. Can someone point me in the right direction?

From the documentation:

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.


Solution

  • Let me first start explaining what the following means

    a read only capacity (meaning Glimpse will collect the information but they can't view it)

    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.