I have an HTTP Module to handle authentication from Facebook, which works fine in classic pipeline mode.
In integrated pipeline mode, however, I'm seeing an additional request pass through for the default document, which is causing the module to fail. We look at the request (from Facebook) to retrieve and validate the user accessing our app. The initial request authenticates fine, but then I see a second request, which lacks the posted form variables, and thus causes authentication to fail.
In integrated pipeline mode, an http request for "/" yields 2 AuthenticateRequests in a row:
A request where AppRelativeCurrentExecutionFilePath = "~/"
A request where AppRelativeCurrentExecutionFilePath = "~/default.aspx"
That second request loses all of the form values, so it fails to authenticate. In classic mode, that second request is the only one that happens, and it preserves the form values.
Any ideas what's going on here?
UPDATE: Here is an image of the trace from module notifications in IIS. Note that my module, FBAuth, is seeing AUTHENTICATE_REQUEST multiple times (I'd expect 2 - one for authenticate and one for postauthenticate, but I get 4).
I'm starting to believe this has something to do with module/filter configuration because I've found a (Vista) box running the same code that doesn't fire these events repeatedly - it behaves as expected. I'm working through trying to figure out what the difference could be...
Thanks!
Tom
My solution was to add the following code at the end of Application_BeginRequest:
if (Request.RawUrl.TrimEnd('/') == HostingEnvironment.ApplicationVirtualPath.TrimEnd('/'))
Server.Transfer(Request.RawUrl+"Default.aspx", true);
DefaultHttpHandler is not supported,
so applications relying on sub-classes
of DefaultHttpHandler will not be able
to serve requests If your application
uses DefaultHttpHandler or handlers
that derive from DefaultHttpHandler,
it will not function correctly. In
Integrated mode, handlers derived from
DefaultHttpHandler will not be able to
pass the request back to IIS for
processing, and instead serve the
requested resource as a static file.
Integrated mode allows ASP.NET modules
to run for all requests without
requiring the use of
DefaultHttpHandler. Workaround
Change your application to use
modules to perform request processing
for all requests, instead of using
wildcard mapping to map ASP.NET to all
requests and then using
DefaultHttpHandler derived handlers to
pass the request back to IIS.
Hmmm, or this could be the issue.
ASP.NET modules in early request
processing stages will see requests
that previously may have been rejected
by IIS prior to entering ASP.NET,
which includes modules running in
BeginRequest seeing anonymous requests
for resources that require
authentication ASP.NET modules can run
in any pipeline stages that are
available to native IIS modules.
Because of this, requests that
previously may have been rejected in
the authentication stage (such as
anonymous requests for resources that
require authentication) or other
stages prior to entering ASP.NET may
run ASP.NET modules. This behavior is
by design in order to enable ASP.NET
modules to extend IIS in all request
processing stages. Workaround
Change application code to avoid
any application-specific problems that
arise from seeing requests that may be
rejected later on during request
processing. This may involve changing
modules to subscribe to pipeline
events that are raised later during
request processing.
http://learn.iis.net/page.aspx/381/aspnet-20-breaking-changes-on-iis-70/
Related
I am having a problem implementing Microsoft's latest Identity 2.0 in my ASP.net 4.5 Web Forms project. This is my scenario...
I have downloaded the latest Webforms.Samples code from https://aspnet.codeplex.com/SourceControl/latest and pretty much performed a straight port (for the purposes of testing) into my project.
In development, the code/implementation works correctly, when we move to our IIS 7.5 staging server, after a period of time (usually 3 or 4 hours, but varies) the test users experience the following problem...
When they login, the login process appears to run correctly and redirects them back to the specified return url, but the authorisation is not complete/recognised and they get immediately returned back to the login page.
I should say that the login page/process doesn't fail (no errors) and the underlying code return 'success' (as this is the only path that will invoke the redirect), but the actual mechanism appears to be passive. To prove this, I have created a test page that simply echoes the user's identity and even immediately after an apparently successful login, the user identity is anonymous.
The only way I have found of fixing the issue is to restart the web application and again it runs fun for a while.
Can anyone give me any pointers on where I can look to begin to debug this issue or what the cause might be?
Thanks.
ASP.NET_SessionId + OWIN Cookies do not send to browser This page seems to provide a workaround to the issue by creating a session on application start up.
Starting with this great analysis by #TomasDolezal, I had a look at both the Owin and the System.Web source.
The problem is that System.Web has its own master source of cookie information and that isn't the Set-Cookie header. Owin only knows about the Set-Cookie header. A workaround is to make sure that any cookies set by Owin are also set in the HttpContext.Current.Response.Cookies collection.
The workaround I created is now outdated: I've made a small middleware
(source, nuget) that does exactly that, which is intended to be placed immediately above the cookie middleware registration.
Use Microsoft's suggestion of a SystemWebCookieManager instead.
I need to simulate web response for web requests during some tests. I was going to use fiddler core for that. So fiddler just acts like a proxy and Im able to set response for every request I like. But I need to run something like console application or standalone application to make fiddler core able to intercept the requests. And I need it to be somehow initialized inside my asp.net mvc test application, so that tester could access these fake data, by just using the urls, without the need to run fiddler or any other applications.
For now I tried to run my fiddler application in Controller action method, but it doesnt intercept anything.
I also tried to add URLMonInterop.SetProxyInProcess("127.0.0.1:"+ myPort, ""), but it doesnt work either.
Is there any way to self host fiddler core app and make it intercept the requests?
UPDATE:
In the end I managed to host fiddler core inside asp.net mvc app. I made initialization in a static method of a static class and it did the trick. Also, for some reason after calling shutdown and then performing initialization again I cant proxify anything. I even cal GC.Collect, nothing helps, but refreshing the host process, in my case IIS express.
As documented, SetProxyInProcess affects URLMon clients only, and .NET doesn't use URLMon for networking.
.NET clients typically pick up the current proxy setting automatically, but if you're running FiddlerCore in a different user account, that's not going to work (and you probably don't want your mocker to be messing with any traffic except your test application). So, instead you should configure your application explicitly to proxy its traffic through your FiddlerCore instance; see http://fiddlerbook.com/fiddler/help/hookup.asp#Q-DOTNET and http://fiddlerbook.com/fiddler/help/hookup.asp#Q-IIS and if your services are local http://fiddlerbook.com/fiddler/help/hookup.asp#Q-LocalTraffic
I would like to know if there is any way I can check if the request for static files like images/css etc is handled from asp.net pipeline or not.
I have set runAllManagedModules=false in web.config and added ignore routes as well.
The load times have come down. Which indicates that the requests are probably not passing through the asp.net pipeline.
However, is there a way I can ascertain the same?
Browsers i Used: IE/ Firefox
If request goes through ASP.NET request pipeline, it should call all the registered http-modules.
Add custom http-module (if you don't have one).
Put breakpoint inside.
Run app in debug mode.
Initiate request of any static content.
If breakpoint is reached, request probably goes through ASP.NET pipeline. To make sure, you can check the url of the request in debug mode.
I have gone through the links mentioned below,
iis forum and HttpModules & Server.Transfer / Server.TransferRequest / RewritePath problems. but unable to catch the concept behind these transfer methods.
How are they works? And which one is preferred in different situation?
Can someone explain me TransferRequest vs Transfer methods for server side transfer in asp.net and its roles?
Thanks in advance
HttpServerUtility.Transfer Terminates execution of the current page and starts execution of provided URL.
This basically maps and executes a new ASP.NET Page (or serves a static file) corresponding to the url provided. It does this in-place in the current request pipeline, without applying new configuration to the new url, or re-running IIS modules for the new url. Because of this, its very fast, but it also prevents a lot of scenarios that are possible with TRQ.
HttpServerUtility.TransferRequest Performs an asynchronous execution of the provided URL.
This is a full IIS child request under the covers, which allows it to re-run the entire request pipeline for the new request as if it was a separate request, getting the correct configuration for it, and running all of the normal IIS modules including authentication, authorization, etc. For example, IIS will apply the authorization rules for the new url, as opposed to the previous url.
TransferRequest re-runs the entire request pipeline as if it were a separate request. This means that IIS and ASP.NET modules are re-applied; authentication and authorization rules for the new URL will be honored. Note that TransferRequest requires the integrated pipeline mode of IIS 7+, and the transfer can be to an ASP page or another resource like an XML file.
Transfer transfers execution from one ASP page to another ASP page on the server. Unlike TransferRequest, IIS and ASP.NET will NOT verify that the current user is authorized to view the resource delivered by the Transfer method. If you need to force reauthorization, and integrated pipeline mode is not an option, call Redirect instead of the Transfer method. Redirect triggers a client-side redirect so that the new request will be subjected to all authentication and authorization logic of IIS and ASP.NET.
Is it at all possible to inject a request into IIS for a page, have IIS and ASP.Net handle it as normal, but get the response as html handed back to me programmatically?
Yes, I know that I could connect to port 80 using WebRequest and WebResponse, but that becomes difficult if you are accessing the IIS server from the same physical machine (loopback security controls et al).
Basically, I want to inject the request (eg for http://example.org/MyPage.aspx) between the points at which IIS would normally talk to the browser, and the point at which it would route it to the correct ASP.Net application, and get a response back from IIS between the points at which ASP.Net/IIS applies the httpfilters and hands the html back to the browser.
I'm predominantly working with IIS7 so if there is a solution that works just for IIS7 then thats not an issue.
You could implement a custom HttpModule, which would give you access to the IIS pipeline, including the final response. However, you would still need to initiate a request to IIS to actually kick off processing. Not sure if this would work for you.
From the MSDN documentation:
An HTTP module is an assembly that is
called on every request that is made
to your application. HTTP modules are
called as part of the request pipeline
and have access to life-cycle events
throughout the request. HTTP modules
therefore let you examine incoming
requests and take action based on the
request. They also let you examine the
outgoing response and modify it.
Gave you looked into the WebCkiebt class? You can make the request and get the response HTML.
http://msdn.microsoft.com/en-us/library/system.net.webclient.downloadstring(v=VS.100).aspx