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.
Related
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.
I want to silently check for Session existence without Posting back page by using AJAX Timer and AsyncPostBack Trigger.
Now, I would like to know is there anyway to silently check whether ASP.NET C# if (Session["email"] = null) { Response.Redirect("Logout.aspx"); } something of this kind to check for every 10 seconds without Posting Back Page and without using AJAX by using something like jQuery or any other technology that is supported by .NET?
The server can push to a loaded page if you use an asynchronous controller with a partial view which is loading every set amount of time.
http://msdn.microsoft.com/en-us/library/ee728598.aspx
there is only one way to get to the server. send a request. that can be a "standard" request where the browser will refresh the screen when a response is sent. the other type of request is a ajax request. the difference is an ajax request contains a header to inform the server it's an ajax request. when the browser receives the response it will allow the developer to decide what to do with the response. either way a full request/response exchange takes place the only difference is how the browser handles the request.
jquery is a javascript library that includes functionality to make ajax request easier to setup.
to answer you question no, there is no way around making a request.
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)]
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.
I've been using user controls extensively but never use a HttpHandler and was wondering if I am doing something suboptimal or wrong
Unfortunately your question is a little like "Should I use a sandwich or a cement mixer". HttpHandlers and User controls are completely different things.
HttpHandlers are used to process HTTP requests. For example, if you wanted to dynamically create an RSS feed, you could write an HTTP handler that handles all requests for ".rss" files, creates the output and sends it back to the user.
User controls are used within ASPX pages to encapsulate units of functionality that you want to re-use accross many pages.
Chances are, if you're using user controls successfully, you don't want to use HttpHandlers!
Basically a user control is a piece of server logic and UI. An HTTP Handler is only a piece of logic that is executed when a resource on your server is requested. For example you may decide to handle requests for images sent to your server through your own handler and serve images from a database instead of the file system. However, in this case there's no interface that the user sees and when he visits a URL on your server he would get the response you constructed in your own handler. Handlers are usually done for specific extensions and HTTP request types (POST, GET). Here's some more info on MSDN: http://msdn.microsoft.com/en-us/library/ms227675(VS.80).aspx
Expect a better answer (probably before I finish typing this) but as a quick summary.
A user control is something that can be added to a page.
A HttpHandler can be used instead of a page.
Just to clarify the question. I was reading the Hanselman post
http://www.hanselman.com/blog/CompositingTwoImagesIntoOneFromTheASPNETServerSide.aspx
and thinking that I would never solved the problem with a HttpHandler, maybe with a simple page returning a binary content.
This led me to think that I should add HttpHandler to my developer tool belt.
Even an Asp.Net page is an HttpHandler.
public class Page : TemplateControl, IHttpHandler
A user control actually resides within the asp.net aspx page.