We have an HTTPModule whose sole purpose is to do "url rewriting". By definition of an HTTPModule, ALL browser requests (html, css, javascript, images, etc) go through the event handlers of this class.
During the signin process, we are catching the moment when the user switches from "anonymous" to "signed-in" user in the Global.asax's Profile_OnMigrateAnonymous event handler. One issue we're finding is that when the user signs in, the Profile_OnMigrateAnonymous event fires, seemingly, for possibly EVERY resource within the request to generate the page to the user - namely, the html, css, javascript, images, etc. It was my understanding that this event will fire only ONCE. Why would it be firing multiple times? Is it a result of our registered "url rewriting" HTTPModule? Is there a way we can configure the application to only fire that event once?
For normal resource reqeusts (css/js/img etc) IIS handles the request directly. It only passes to the asp_net worker requests for specfic filenames (such as .aspx and .asmx).
Your HTTPModule is basically forcing IIS to forward all requests to the worker process, hence each request is firing off the Profile_OnMigrateAnonymous.
I don't think you can bypass the call to Profile_OnMigrateAnonymous, however you could implement a bit of code to check for a an .aspx/.ascx etc file name and only then perform the actual actions specified.
Related
Is there no way to detect if the current request is being mapped via ASP.NET 4.0 URL routing?
I have an HTTP module that handles the application's BeginRequest event. I have found that this handler is called for all file types, including CSS, JS, image files, etc., and I just want to perform an action if the target file is an ASPX page.
In the case of routed pages, all the properties of the HttpRequest object reflect the requested URL, and not the ASPX page that the request is being mapped to. How can I determine if the request will be handled by an ASPX file?
Thanks for any suggestions.
Inside of the Begin Request event a Handler has not been defined for the specific URL.
So there is no way of determining what will actually end up handling that URL because IIS has yet to decide. That happens after Begin Request has been fired, that is why all file types are being called.
That's one of the reasons why Begin Request is not a good event to really execute code on that needs to target specifically .NET files. A good use for the Begin Request method is adding cookies or headers to either a request or response. Those can be tacked on without a problem no matter what ends up handling the request.
As mentioned before I would suggest a Base Class that inherits from System.Web.UI.Page that all your other pages inherit from, or create a Master page.
Now without specifically knowing what you are trying to do it's hard to give a good solution. It may be possible to test a URL to check if it'll be fired by a Route, but I don't know how and it also seems excessive when you can handle it through a base class or master page.
You can create a BasePage as a base class for all pages in the application, and handle the Page_Load event there instead of using an HTTP module.
I'm calling a static Page method via javascript that takes between 5s and 10 min. I'd like to give my user the choice to either continue waiting for the request to complete or not, and use window.setTimeout() to check back every 30s.
I've tried both location.href = '/newpage.aspx' or firing a button's click handler (which does similar redirect) to redirect the user prior to completion of the page method, to no avail. I can immediately send user to a simple html page, but a redirect to any aspx page involving server-side appears to block. When the page method finally completes, the redirect does succeed.
Is this:
a browser issue? If all modern
browsers support at least 2
concurrent requests per domain, why
wouldn't this work?
a framework
limitation?
a desirable design
pattern or even possible? I've
checked, and after redirecting to an
HTML page, the original request continues processing (db updates, no problem).
Are Page method calls simply not asynchronous from a "concurrent HTTP request" perspective?
Any insight greatly appreciated!
It sounds like you're blocking on InProc Session, which is limited to one concurrent request per unique session. If you don't need access to the Session in your page method, you can disable it by modifying the WebMethod attribute:
[System.Web.Services.WebMethod(EnableSession=false)]
What is AsyncPostBack, SyncPostBack and what is the difference between those methods?
An asynchronous postback is accomplished using javascript to send an XMLHttpRequest, known as AJAX, without leaving the web page you are on. A synchronous postback is a normal form post request from the web page, resulting in a complete request cycle and a (re)display of the same or a different web page. The difference is that with an asynchronous request the web page stays the same and the user can continue to interact with it while the request is taking place. This can make the interface seem more responsive to the user and improve the experience. In a synchronous, or full, postback the web browser must wait while the request is sent back and the new page is loaded. You also lose, if you don't maintain it on the server and reset it on the new page, any state on the original web page.
When we write our own custom HTTPHandlers aren't they behave the same way as ICallBackEventHanlder does? we use both to make ajax calls from our web page, isn't this correct? or my understanding wrong, I wont doubt if it is :(
Obviously HTTPHandlers are more broader concept since a web page (.aspx) etc are also http handlers.
A ICallBackEventHandler is for integration with a page -- a handler is for anything. A callback handler is useful when you want to do an ajax request from the client-side of a page, and from that handler you still want access to all of the controls on the page, their re-saturated state that comes from ViewState, etc. An http handler has no access to the page or its state. A callback handler can also push some state changes back to the client. For example, a callback handler might render something which requires the __EVENTVALIDATION field on the client-side to be updated.
I've got an HTTPModule that does some role-based page access security (I'm having to retrofit some security into some code that we've acquired).
I've noticed that in one instance that it doesn't fire on a Server.Transfer.
Here's a snippet of the code:
' move to target page
Select Case eTransferMethod
Case TargetPageTransferMethod.Redirect
Page.Response.Redirect(strPage, False)
Case TargetPageTransferMethod.Transfer
Context.Handler = Me
Page.Server.Transfer(strPage)
Case TargetPageTransferMethod.None
' Do nothing
End Select
The case that I'm talking about here is the TargetPageTransferMethod.Transfer case. The page will be an .aspx page.
Now I know that AcquireRequestState is fired on other Server.Transfer calls in this code. In fact it gets fired on the postback when a button on the page transferred to is clicked. Ironically my security code is bypassed on the transfer to this page but denies access on the postback when this page's cancel button is clicked! :eek:
I'd post further details of the codebase but it's so convoluted and sprawling it'd be a nightmare to explain.
So basically I'm asking 'What might cause the AcquireRequestState event in an HTTPModule to not fire when a Server.Transfer is called?'
The way to get around this is to create a custom HttpHandler that inherits the System.Web.UI.PageHandlerFactory class.
You can then override the GetHandler method which is called whenever a page instance is created, both on Response.Redirect and on Server.Transfer.
Register this new handler to use the "*.aspx" extension and all pages will automatically use the new handler. This allows you to do custom authorisation on Server.Transfer as well as use a dependency injection framework (e.g. MS Unity).
I can understand it being called on a post back, as that is another request from the client, but Server.Transfer doesn't initiate a new request, it transfers execution from one page to another.
As the AcquireRequestState event is fired "when ASP.NET acquires the current state (for example, session state) that is associated with the current request" - this would occur on the initial request from the browser, but not on the server transfer as the server didn't get another request, you're just asking it to process a different page.
A key comment is this one from the HttpServerUtility.Transfer documentation:
ASP.NET does not verify that the current user is authorized to view the resource delivered by the Transfer method. Although the ASP.NET authorization and authentication logic runs before the original resource handler is called, ASP.NET directly calls the handler indicated by the Transfer method and does not rerun authentication and authorization logic for the new resource. If your application's security policy requires clients to have appropriate authorization to access the resource, the application should force reauthorization or provide a custom access-control mechanism.
Server.Transfer doesn't reprocess the entire HTTP pipeline for the destination page. It just calls the destination page's HttpHandler. Because of this, you shouldn't see any of the earlier applicaton events get fired.