Monthly Archives: December 2013

A Glimpse into Windows Azure

With Glimpse, we  can peek into all things server side. We can inspect ASP.NET, ASP.NET MVC, Entity Framework, ADO.NET and much more through plugins. Since many developers are making use of Windows Azure to host their web applications, we are happy to announce a first public preview of two Windows Azure tabs in Glimpse!

Glimpse.WindowsAzure.Storage

The Glimpse.WindowsAzure package will display runtime information for a Cloud Service or Web Site. Glimpse.WindowsAzure.Storage collects and displays information about traffic from and to storage and gives best-practice advice. More information about the information offered through these new tabs can be read on Maarten’s blog.

It would be great if you could give these two packages a try and give us feedback! Here’s how:

Note that the Windows Azure tabs are still in a preview phase and rough edges may be in there. We’re still looking at load balanced environments. You can implement Glimpse’s IPersistenceStore but we would like to have a zero-configuration setup in place.

Enjoy the new year!

Glimpse ASP.NET 1.7 Released – Cache Tab

The community around Glimpse is continuing to swell as each release includes the effort of more and more people. This release is comprised almost entirely of contributions from outside the “founders team” of Anthony and I (who have been focusing much of our effort on the forthcoming release of version 2.0).

Caching Tab
The big feature in this release is the new Cache tab, which provides insight into the state of the application’s usage of data caching via the HttpRuntime.Cache object.

Cache Screen Shot

Async Patch
Additionally we have release a patch fix for a small number of users which have experienced problems with the Async support we released in 1.8.0 and crossing AppDomain boundaries. This has come up for users when they navigate to a page that contain a ReportViewer control, or using VS2010/12 Dev Web Server (instead of IIS Express or full IIS), or a couple of other edge cases.

A full fix for this will come in v2 but if you run into an exception that reads something similar to:

Type 'System.Web.HttpContextWrapper' in assembly 'System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.

you simply need to add the following as an app setting element:

<appSettings>
    ...
    <add key="Glimpse:DisableAsyncSupport" value="true" />
    ...
</appSettings>

If this affects you and you are interested in reading more details on it, head over and take a look at issue #632.

Lastly, we’re also releasing Glimpse.Core 1.8.1 and version 1.5.2 of our MVC packages, each which with several bug fixes. Here’s the full details:

Release Notes

  • Glimpse.ASP.NET – Middleweight release 1.7.0
    • New data caching tab for HttpRuntime.Cache
    • Improved handling of connection strings in Configuration tab including the ability for a user to define which keys/values inside a connectionString which should be obfuscated
  • Glimpse.Core – Featherweight release 1.8.1
    • Fixed style issue which forced Glimpse tables to be full width
    • Added new client events around HUD init process
    • Fixed encoding issue in the AJAX HUD ticker
    • Fixed issues with certain CORS requests failing due to unexpected header modifications
    • Fix to HUD’s poor wrapping on small screens
    • Fixed possible in-memory persistence store thread issue
    • Update structured layouts so titles can have the new casing logic applied
    • Updates to make Glimpse.axd compliant with content security policies
    • Allow users to disable use of Logical Call Context via Glimpse:DisableAsyncSupport AppSettings switch
  • Glimpse.MVC* – Featherweight release 1.5.2
    • Fixed bug with model binding tab and some complex models

Special Thanks
As mentioned above, this release was a big team effort. In particular we’d like to thank:

  • Christophe Gijbels
    • #676 Made in-memory persistence store thread-safe
    • #658 Update Glimpse.axd to CSP compliant
    • #671 Improved handling of connection strings in Configuration Tab
    • #655 Updated complex models processing to work correctly in the model binding tab
  • Bryan Hogan
    • #675 Update the Cache Tab ready for release
    • #649 Removing commented out from request tab
    • #648 Update resource result to not generate null reference exception when dealing with QueryString
  • Steve Ognibene
    • #641 Improve WebForms viewstate smoke tests
    • #636 Addition coverate for improving WebForms viewstate smoke tests
  • Andrew Ma
    • #104 Prototype implementation for caching tab
  • Dorin Manoli
    • #677 Update HUD wraps to fix incorrectly on small screens

And for the great issue reports, we’d also like to thank:

Release Details
For a full list of changes, issues and commits you can use any of these links into GitHub:

Thanks to everyone who helped out with this release and the Glimpse team would like to wish you and yours a happy holiday and bug-free New Year!

dj

Protect Glimpse.axd with your custom runtime policy

Let’s first start with a quick recap on how Glimpse decides whether or not to aggregate and store diagnostic data for a specific request and how it protects its own resources for unauthorized access. (Glimpse resources are, for instance, the Glimpse client JavaScript file, the metadata that makes up the Glimpse panel, but most importantly the aggregated diagnostic data of the last and previous requests.)

To make sure Glimpse doesn’t show possibly sensitive diagnostic data, it allows you to create a custom runtime policy. This, based on your rules, authorizes or prevents the Glimpse Runtime from returning the aggregated data or even from running in the first place – all of this is determined per request. The Glimpse cookie for instance, which is what drives the “Turn Glimpse On” button, is checked by the ControlCookiePolicy, and is not used to prevent access to aggregated data but rather to inform the Glimpse Runtime whether or not it should collect information during the execution of a request.

All is not lost however. Glimpse is secure by default because it registers, out of the box, the LocalPolicy. The LocalPolicy is a runtime policy that checks whether or not a request has been made from the local machine and if this is not the case, then Glimpse will not aggregate data and certainly not return (previously) aggregated data. This is also the policy that must be ignored in the web.config if you would like to get Glimpse diagnostics from a remote server.

Now if you remove the LocalPolicy, then basically everything is out in the open. There is nothing protecting you from having Glimpse gathering diagnostics and returning this to the person making the request. You could disable Glimpse completely in the web.config by setting the defaultRuntimePolicy=”Off” in the glimpse config section, but then there is not much for you to personally get either.

So you need to replace the LocalPolicy with your own custom security policy. Which sounds harder than it is – usually only a few lines of code are involved. There might already be an example of such a policy in your project (albeit commented out) if you installed the Glimpse.AspNet NuGet package, just look for a file named GlimpseSecurityPolicy.cs

GlimpseSecurityPolicyExample

What does this example policy do? Well if you compile this as is, then Glimpse will discover this policy and will ask the policy, by calling Execute at then end of a request (ExecuteOn has a value of RuntimeEvent.EndRequest), whether the client is allowed to see the aggregated data or not. This example will only allow this if the current authenticated user is a member of the Administrator role, but you can put any kind of logic in there if you want, just keep in mind that this will be called for every request that is being monitored by Glimpse.

In case you’re wondering why the check is done at the end of the request instead of the beginning (as Glimpse might already have monitored the request then), it’s because some things like the current User might not yet be set in the beginning, hence disabling Glimpse for every request. But depending on your logic (IP check for instance) you can change this value to RuntimeEvent.BeginRequest

Securing Glimpse.axd

Now all of this was already possible with previous versions of Glimpse. But there was one thing that was not protected by such a custom security policy and that was the Glimpse.axd. This was due to the fact that if the same runtime policies would have been applied, then the Glimpse.axd might not be accessible in the first place because the ControlCookiePolicy could not find the Glimpse cookie and you need (at least to begin with) the Glimpse.axd to set the cookie (and maybe add the bookmarklets to your favorites bar for later use). This is why the runtime policies were explicitly being ignored by Glimpse for the default resource aka Glimpse.axd

You might wonder why you would secure the Glimpse.axd in the first place? Although it doesn’t give you access to the aggregated data, there is still quite some information being shown that might be useful to persons with bad ideas. Today the Glimpse.axd shows you how Glimpse is configured, maybe tomorrow we would like to provide you with the possibility to make changes to the configuration at runtime, who knows.

Securing Glimpse.axd as we used to do
There were several ways to lock the Glimpse.axd down because Glimpse wouldn’t. I’ll only show two of them, because some others are a little bit hacky and those two mentioned below can still be used today if you want to:

  1. Leverage the ASP.NET Security Model : By adding a location element to your web.config you can restrict access to the Glimpse.axd to Administrators only. Of course this is only possible if your authorization checks can be satisfied with a role checkglimpseaspnetlocation
  2. Security by obscurity : We’ve been talking about Glimpse.axd but there is no compelling reason to keep it named like that, you can name it whatever you like as long as you adapt your web.config accordingly you are good to go. But again, it’s not bullet proof if somebody can guess really wellSecurityByObscurity

Securing Glimpse.axd the way forward
As of release 1.7.0 of Glimpse, you can now secure the Glimpse.axd by using the same custom security policy as shown above. This has the benefit that your authorization rules with regards to Glimpse are stored in one place being your custom security policy and you no longer need to rely on security by obscurity or role checks (if that was even possible). And there is only one thing that you need to do for that which is modifying the ExecuteOn property of your custom security policy, so that it will not only be called at BeginRequest or EndRequest but also when a resource is being executed (our default resource aka Glimpse.axd) by updating ExecuteOn to:

public RuntimeEvent ExecuteOn
{
    // The bit flag that signals to Glimpse that it should run on either event
    get { return RuntimeEvent.Endrequest | RuntimeEvent.ExecuteResource; }
}

GlimpseSecurityPolicyExampleWithExecuteResource

Voila, that’s all there is to it

Now there are no more reasons why your Glimpse.axd can’t be secured. If there is something not clear or working, don’t hesitate to contact us on our issues list

Glimpse: What’s the current status?

Have you looked at the Glimpse issue list on Github recently? New issues are being posted daily, which means the list is constantly changing. How do you know what is going to be released next and who is contributing to it?

Introducing the Status Dashboard

No more filtering, confusion, searching! The status dashboard makes it clear what is currently being developed for the next release.

What is going to be released next?

When you submit an issue on github, the Glimpse team will categorise the issue into the core nuget packages: Core, EF, ADO, ASPNET, MVC and Webforms.

Packages

If one of the packages is broken at the moment this will be highlighted in red and we will indicate what exactly the bigger issue is.

Who is contributing?

We have a lot of people contributing to Glimpse and we want to acknowledge them in every way possible. The bottom half of the status dashboard acknowledges all those that have reported issues

StatusBoard-Reporters

or contributed to the code base

StatusBoard-PullRequests

This last part of the status dashboard is really important for us, as we want to acknowledge those who contribute in whatever way they can to the project.

Feedback

The next time you are wondering what will be released next or if your issue will be resolved soon, take a look at the status dashboard.

As always we welcome your comments and suggestions! Any insights are welcome.