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.
Related
I have code in my project which changes the URL containing the text as querystring to number to get the data from the database. I am checking the querystring in page load and if it contains the name rather than the number I am mapping it to the numeric key. Now I have to execute the page life cycle again. I had two choice either use the
Response.Redirect
but I do not want the URL in the client browser to change so I went with the
Server.Transfer
The problem I started facing is that I have a custom httpmodule which is used to log the URLs in the database. I realized that
BeginRequest
in the http module is not firing after the
Server.Transfer
My application is working fine in the case of
Response.Redirect.
I am not sure how and why Server.Transfer is skipping my HttpModule and if it is how it works ?
Server.Transfer is a completely server side mechanism - it instantiates the new Page class based on the path to .aspx file and transfers the execution there (including all state information for the built-in objects). There is no new request and nothing goes again through the pipeline (so among other things HttpModules are not re-executed), as the hosting part is interested this is still the same request - the response has just been created from different page than it was originally planed.
Response.Redirect falls to standard HTTP mechanism. On server side it throws an exception to break the current execution pipeline and return an 3xx status code. The browser then issues new request for the resource under the new URL. Both requests go through full pipeline on the server side.
So the answer to your question boils down to the fact that HttpModules are being executed for every upcoming request but in case of Server.Transfer there is no new upcoming request.
Page Load, as a sentence of 2 words, means when the page is loaded, means, when all elements are loaded.
Let's say I have a page called Ask.aspx, and this page is only allowed to users who have signed in, so technically I would write something like this :
if(Session["id"]==null)
Response.Redirect("Login.aspx");
This mean, that I'm testing the Session AFTER the page loads, theoretically, I think it sounds wrong, now of course I won't notice it, it will be fast, I will try to access the page, then I'm redirected to Login.aspx, but... is it correct to test the Session on Page Load method?
The Page_Load is part of the page lifecycle. It is called when the Server loads the page, not when the Client loads the page...
So this is the correct place to check the Session Variable...
You're actually saying: Before I post the page back to the client, check if I have the ID property set for this session... If I don't - tell the client to redirect to the Login.aspx page...
This is the correct way of doing this...
I recommened you also read about Server.Transfer. The difference between it and Response.Redirect is that in Server.Transfer the server itself "redirects" to another page and outputs the result of the new page back to the client (without the client knowing about it).
If you are trying to limit access to specific pages, you would be better off using forms authentication.
http://support.microsoft.com/kb/301240
It is fairly easy to setup and it allows checking of credentials before the request is passed to the asp.net pipeline. In what you are doing, your page goes through the entire lifecycle (controls are rendred and bound to data, access to database, calls to web services etc.) before the request is rejected. Depending on your situation, this might be costly and will not scale well.
Edit: You can also hook in to the AcquireRequestState event in the global.asax. This will also spare the entire page life cycle.
Hi I have web app which stores certain things on a page in a cookie when the page posts back in case the user doesn't finish what they're doing and come back later. But now I must do a javascript time-out and actively save the info to the cookie rather than wait for the user to postback. All my cookie code is on server side where I use Response and Request objects to read and write cookies and I want to leverage that. So I would like to just use ajax calls to a webservice. Is there a way for me to access Request and Response objects and read and write cookies to the browser via those objects during a webservice call? Or should I just go with javascript?
EDIT: Sorry i wanted to specify that I would like to use jquery-ajax.
Implement an ajax callback on a timer that posts back every n number of seconds. When the ajax posts back, check your constraints and simply update the cookie.
OK so I created the static web method on .cs side of the page and in the method I enable session. So this way, I can save stuff to cookie by making ajax calls and using my already existing .cs cookie code.
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.
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.