Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Execute function which returns RuntimePolicy isn't invoked #780
When I run my app in a debugger, the "Execute" function in GlimpseSecurityPolicy is only invoked when ExecuteOn returns RuntimeEvent.Initialize.
This causes problems when hitting certain routes which I want to exclude Glimpse from touching the HttpContext of.
The issue with routes is related to Paul Atkin's post here: #736 however I feel if the "Execute" function invoked properly, then maybe I can code around this.
Just did some digging through the code and did a bit of hacking... and it seems that when I add the following to the ignoreTypes:
Then my policy gets invoked for any RuntimeEvent... however, even though the policy is set to "Off" when invoking the service, the service still has security issues. Hmm...
I guess this ticket can be closed/ignored.
I spent quite a few hours with the Glimpse code and realized it doesn't work quite like I thought. I thought turning the policy to "Off" would solve the issues, but that's not the way Glimpse works. It already makes changes prior to checking policies.
I wasn't able to track down the root cause of my particular issue, but I know it's created in the Glimpse.AspNet.HttpModule.Init routine. The only way to solve it in my case would be to have the blacklist URI policy applied in the Init routine prior to "BeginRequest" etc being invoked.
@bsimanov I think I know what the problem might be, but I need to make sure first if my assumptions are correct when reading your comments:
That is normal, as
What do you mean exactly with I'd like for Glimpse to be off as it breaks the service security What is the exact problem that Glimpse is breaking here?
Here I'm not following you anymore, a policy will only be invoked for all the runtime events it specifies that it wants to handle (BeginRequest, EndRequest, ...)
There are multiple policies being checked and currently there is no order defined, this might mean that even though your custom policy says
Does all of the above mean that you want Glimpse to prevent accessing the request's input stream so that your code has full access to it? Is that the error you're getting? Because we are aware of such a case when the
If that is the case, then you could test that by disabling the
Could you confirm/deny that it is the same issue, and if not, could you elaborate on the exact issue your are trying to work around? Put otherwise: what is exactly failing if Glimpse touches the
@CGijbels thanks for the very thoughtful response. I guess I didn't write too well, because there's some misunderstanding.
I've spent a LOT of time on this and finally found the issue! It's actually a problem with multi-part messages, which cause security issues when dealing with proxies (which is what I assume Glipse creates with the Castle Proxy). The issue and resolution are described here: http://support.microsoft.com/kb/908573 (Workaround section).
I tested the workarounds in the client code (NuGet), but I doubt the developers of NuGet will change that piece of code -- I'll report the issue there regardless.
As I stated earlier, it would be nice to have routes which are blacklisted from being proxied by the Castle Proxy.
Do you know if this is possible?
Just to contribute something back to the project, I found a small bug.
https://github.com/Glimpse/Glimpse/blob/master/source/Glimpse.AspNet/Tab/Routes.cs, line 164 should be changed from:
This will at least show you what type of route it is... I tried to figure out a way to actually get the details from RouteMagic, but RouteBase isn't exposed.
@bsimanov regarding blacklisting specific urls: Did you try to use the
Now it might still have to pass through the proxies, as the proxies are put in place at the start and apply for all requests, the only difference with requests that should not be treated because one or more runtime policies object, is that those take a shortcut directly to the original code instead of Glimpse specific code.
Regarding your last comment, feel free to create a separate issue for that and if you could provide a pull request with the change you made than we'll be happy to pull it in as well as it seems a good suggestion. That way your contribution will be a lot more visible on the Glimpse status board and in the release notes later on
@CGijbels Yes, I've tried the uri policies, no go... the proxy is already active.
I've created a simple solution to recreate the issue. Warning: this may cause you to lose sleep and hair! :)
In console, run the client. Run it again while turning the Glimpse defaultRuntimePolicy on/off. You'll see the issue :).
@PaulAtkins thanks for confirming! @CGijbels per your recommendation, I'll figure out how create a "pull request" and contribute to the project. Besides the visibility, it's good training to support the open source community.
@bsimanov hmm, I'm running the application but I don't get an exception?
When I hit http://localhost:52459/defult.aspx, my name is shown as well as the Glimpse client panel
When I hit http://localhost:52459/myservice I get a 200 with my account name as description, so far so good no?
When I post to http://localhost:52459/UploadStuff I get a 200 with my account name as description, so far so good no?
So I'm trying to get my head around what is exactly going wrong for you? I must be missing a crucial part here?
Even when you go back to the defult.aspx page and show the history tab, you'll see all those posts and get stored in Glimpse...
@CGijbels The reason it's working is because it seems you're just hitting the route in your browser. Instead, use the provided GlimpseIssue.Client.exe, which creates a multi-part message (to upload to the site).
Compile the Client project and execute it from command line.
@bsimanov Alright, I was able to reproduce and the temporary solution is one of the suggestions I made above, namely to remove the
This way you'll loose the Ajax detection, which makes sure the Glimpse client isn't sent back, but if you combine it with the
Problem is that the
Can you confirm that this workaround is working for you?