I’m building an asp.net web application; I’m using an http handler as a filter, because I want the user to be redirected to a certain page if a condition is true. Problem is if the condition is false the page doesn’t load because the http handlers kill the life cycle of the page itself…so, is there any way to avoid this and to load the page properly or am I supposed to use another object to filter?
A handler, as its name suggests, must completely handle the request. If you want every request to be examined and filtered, you want to use an HttpModule.
A good 'getting started' guide can be found here.
Related
I've got an Asp.net MVC action that creates user account(after input validation). And a View containing registration form that invokes this action. While action validates input, user is left with webbrowser waiting for server response and click submit button a few more times. This creates several accounts. Is there a way to prvent user from form resubmition without javascript. I cannot use javascript in this project it is intended for non javascript browsers. Or can you suggest(server) other solution?
EDIT:
This form request use POST method
JavaScript is not allowed because this Web Application is aimed for special web browsers for people with disabilities that do not support javascript
You have to handle the situation on the server-side then, there's no way around that.
There are 3 options that come to my mind atm:
create a cookie and for each submit check if it exists
similar, but using a session object
before creating a new account, always check if the user exists in the database. THIS should be a no-brainer anyway!
You can add a unique hidden token as part of the form. This token can also be saved as part of the session on the server.
When the user posts the form on the first action, the token is validated and a flag set to indicate the request is being processed. The action processed and results presented. If, while awaiting results, the user attempts to repost the request, the token validation fails as the request is still being processed.
On a side node, the main reason people continuously click is that there is no feed back on whether the request was received by the server or not. To this affect, it might be better to redirect the user to an interim page that shows the request is being processed. Which in conjunction with the above can be used to show the request progress and redirect to the appropriate page when completed.
Of-course, you should also consider making the process a bit lighter. So, that the system can respond quickly to input rather than making the user wait.
Is it a requirement to use MVC? I think you can accomplish something similar using WebForms. When the user submit the request, in the code behind you can disabled the submit button like this:
btnSubmit.Enabled = false;
But if MVC is a must be, #walther answer would be correct
This question might be ridiculous, sorry for that.
Which event is best for reading session data - Page_Load or Page_Init event?
Currently I am using Page_Load event for such tasks. But i have seen in an article to do in Page_Init event.
Thanks.
Update: http://csharpdotnetfreak.blogspot.com/2008/11/detecting-session-timeout-and-redirect.html
It doesn't matter, use the event where you need it. A Session variable is stored in server memory(by default), so it doesn't depend on the current page's lifecycle.
http://msdn.microsoft.com/en-us/library/ms178581.aspx
Session is attached with your request while http request passes through ASP.NET pipeline. So before the page processing begins, you have your session with you. Session is stored on the server and is attached to your user request with the help of session id cookie. This cookie identifies each unique request and attaches session data(Session Module does this work).
I think you are confused with ViewState, because ViewState is stored and read in page life cycle (LoadViewState and SaveViewState event)
Also the article that you have pointed is for detecting new sesssions and time outs. It makes sense to do all the checking in Page_Int, so that response is sent as early as possible
You can access the the session data at any any stage of the page lifecycle. It does not affect it in any way. There is nothing like the 'best' or the 'worst'.
Be more consistent. If your request need some kind of INFORMATION (no matter where you store it), then you should check the presence of INFORMATION before excuting the request.
If you store your information in sesssion than use:
Global.asax:Application_BeginRequest
this prevent you from copy-paste single requirement to multiple page.aspx
What is page object in terms of asp.net?
Please give me some information:
How can we use it in asp.net?
and
Why we are using it?
I tried to search on the internet but couldn't find a proper answer that I could easily understand.
ASP.Net WebForms, like other web platforms, is still in the business of generating responses to http requests.
When a user visits a page on your site, the web server (IIS) receives the request. Because your site has a handler set up in a certain way (by default this is done for you automatically), IIS determines that this request will be processed by the ASP.Net runtime. The ASP.Net runtime then looks up what page you requested, and uses that information to create a new page object for this request.
It's worth noting at this point that you get a new page object even if the request is just a postback to the same page the user just visited. This page object only lasts for the life of this one request, and will be discarded when the request is complete, even though the user might still be interacting with the page on their browser. A new postback will generate a new page object. A lot of people have trouble wrapping their heads around this.
Once the page object is created, the ASP.Net runtime goes through a process called the Page Lifecycle. This involves steps like loading View State, loading the Session, binding to data sources, and raising user events. Between each of the stages, an event (such as Page Load) is raised that allows you to run any custom code you want to run at this particular point in the life cycle.
At the end of the life cycle, the html result for this page is transmitted to the browser, so it can be shown to the user. At this point the page object is destroyed, and the worker thread in IIS is free to handle another request.
I understand that Server.Transfer doesn't make a round trip back to the requesting client.
What I haven't been able to learn is if control is simply passed directly to the new request handler you're transferring to or if or if the entire request life-cycle is executed again.
I assume the entire life-cycle is executed again using the transfer URL but wanted to verify this was the case.
Here is what I found through experimentation.
When using Server.Transfer the entire request life cycle is not ran again.
If you write your own Module, hook it into the request life cycle, and call Server.Transfer from that module the rest of the request life cycle will be skipped and the page life cycle will begin immediately.
After completing the transfer page life cycle the request life cycle picks back up with its tear-down events. Note, the HtppContext in for the tear-down events will be the original one you transferred from. That is, the URL and QueryString values will be the same as the original request and not be the URL and QueryString values for the page you transferred to.
Server.Transfer does modify the HttpContext.Request object to contain the new URL and QueryString information during the page life cycle for the page you transferred to.
If you transfer to a resource that is not a page but is text based (e.g. something.xml) the content of that page will be returned exactly as is with its encoding set to text/html.
If you transfer to a resource that is not a page and is not text based (e.g. something.pdf) then an HttpException error will be thrown. This happens even if you have defined a custom Handler for this resource.
It's just passed along, with its state intact. The request lifecycle does not get run again, although the page lifecycle will run for the page you're transferring to.
http://msdn.microsoft.com/en-us/library/ms525800(v=vs.90).aspx
Server.Transfer acts as an efficient replacement for the Response.Redirect method. Response.Redirect specifies to the browser to request a different page. Because a redirect forces a new page request, the browser makes two requests to the Web server, so the Web server handles an extra request. IIS 5.0 introduced a new function, Server.Transfer, which transfers execution to a different ASP page on the server. This avoids the extra request, resulting in better overall system performance, as well as a better user experience.
This link is also helpful -
http://www.developer.com/net/asp/article.php/3299641/ServerTransfer-Vs-ResponseRedirect.htm
My question is simple (although the answer will most likely not be): I'm trying to decide how to implement a server side upload handler in C# / ASP.NET.
I've used both HttpModules (IHttpModule interface) and HttpHandlers (IHttpHandler interface) and it occurs to me that I could implement this using either mechanism. It also occurs to me that I don't understand the differences between the two.
So my question is this: In what cases would I choose to use IHttpHandler instead of IHttpModule (and vice/versa)?
Is one executed much higher in the pipeline? Is one much easier to configure in certain situations? Does one not work well with medium security?
An ASP.NET HTTP handler is the process (frequently referred to as the "endpoint") that runs in response to a request made to an ASP.NET Web application. The most common handler is an ASP.NET page handler that processes .aspx files. When users request an .aspx file, the request is processed by the page through the page handler. You can create your own HTTP handlers that render custom output to the browser.
Typical uses for custom HTTP handlers include the following:
RSS feeds To create an RSS feed for a Web site, you can create a handler that emits RSS-formatted XML. You can then bind a file name extension such as .rss to the custom handler. When users send a request to your site that ends in .rss, ASP.NET calls your handler to process the request.
Image server If you want a Web application to serve images in a variety of sizes, you can write a custom handler to resize images and then send them to the user as the handler's response.
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 ASP.NET request pipeline and have access to life-cycle events throughout the request. HTTP modules let you examine incoming and outgoing requests and take action based on the request.
Typical uses for HTTP modules include the following:
Security Because you can examine incoming requests, an HTTP module can perform custom authentication or other security checks before the requested page, XML Web service, or handler is called. In Internet Information Services (IIS) 7.0 running in Integrated mode, you can extend forms authentication to all content types in an application.
Statistics and logging Because HTTP modules are called on every request, you can gather request statistics and log information in a centralized module, instead of in individual pages.
Custom headers or footers Because you can modify the outgoing response, you can insert content such as custom header information into every page or XML Web service response.
From: http://msdn.microsoft.com/en-us/library/bb398986.aspx
As stated here, HttpModules are simple classes that can plug themselves into the request processing pipeline, whereas HttpHandlers differ from HttpModules not only because of their positions in the request processing pipeline, but also because they must be mapped to a specific file extensions.
IHttpModule gives you much more control, you can basically control all of the traffic directed to your Web application. IHttpHandler gives you less control (the traffic is filtered before it reaches your handler), but if this is sufficient for your needs, then I see no reason to use the IHttpModule.
Anyway, it's probably best to have your custom logic in a separate class, and then just use this class from either IHttpModule or IHttpHandler. This way you don't really have to worry about choosing one or the other. In fact, you could create an extra class which implements both IHttpHandler and IHttpModule and then decide what to use by setting it in Web.config.
15 seconds has a nice small tutorial giving practical example
Modules are intended to handle events raised by the application before and after the request is actually processed by the handler. Handlers, on the other hand, aren't given the opportunity to subscribe to any application events and, instead, simply get their ProcessRequest method invoked in order to the "main" work of processing a specific request.
Take a look at this documentation from Microsoft (about half way down the page in the "The request is processed by the HttpApplication pipeline" section):
http://msdn.microsoft.com/en-us/library/bb470252.aspx
You can see in step 15 where the handler gets its chance to execute. All of the events before and after that step are available for interception by modules, but not handlers.
Depending on what specific features you're trying to achieve, you could use either a handler or a module to implement an upload handler. You might even end up using both.
Something to consider might to use an upload handler that's already written.
Here's a free and open source one:
http://www.brettle.com/neatupload
Here's a commercial one:
http://krystalware.com/Products/SlickUpload/
If you look at the documentation for NeatUpload, you'll see that it requires you to configure a module.