Is there a way to detect page refresh without using viewstate in asp.net webforms ? I was wondering if it was at all even possible since asp.net mvc doesn't use viewstate for example.
I am trying to avoid using viewstate alltogether to keep my page size small.
IsPostBack is not going to work because its a F5 or Pager refresh case not the post back from any event.
You can detect a page refresh on the server-side using IsPostBack. In fact, any code you put in Page_Load in your code-behind will run each time the page is refreshed. Or have I misunderstood your question?
Why can't you just use IsPostback in the code behind with ViewState disabled in the page? This way you can do whatever you need to in the code behind and not worry about ViewState clogging up your page size.
You can disable ViewState in the page by adding the enableViewState flag to the #Page directive.
The only other thing I can think of is to have a piece of javascript code which catches the key press of F5, but obviously this will only capture an F5 refresh and not a Refresh-button refresh.
This site shows how to capture key presses with Javascript:
http://www.go4expert.com/forums/showthread.php?t=2733
The http protocal is stateless and after a response is send to the one how requestet it removes all trace of him except his session. The way webforms work is that it serialize your page state and send it to the client and then back to the server when you make a postback(A form post request). So you can save information about your client in his session about the page he been on before and then check in the session if he request the same page again.
Related
If I leave my current page on a asp.net Web application I want that all sessions get destroyed. For that I am using Session.Abandon() on Page_Unload Event. But if I do a Postback with a normal Button_Click I don't want to fire this event.
It would be awesome if you could help me.
Lingo
First you need to understand how the web works. When you access stackoverflow.com for example your are actualy seeing the past. The page you accessed it's already destroyed on the web server.
Based on that principle when you use Page_Unload or Session.Abandon if you actually close your browser you don't send any request for the web server so the web server didn't know (and don't care even) if you close your page.
For doing like
The page unload description act like this it's after being rendered it's had nothing with the close of the page.
"The Unload event is raised after the page has been fully rendered, sent to the client, and is ready to be discarded.
At this point, page properties such as Response and Request are unloaded and cleanup is performed.'
Reference (https://msdn.microsoft.com/en-us/library/ms178472.aspx)
You need to use javascript for doing this behaviour or try the new websocket that will keep the connection alive and the server could check if the client has lost the link with the server.
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've got a log in page, which upon submission of the login form, displays some information to the user for a couple of seconds before redirecting to the target page.
This was working fine with a timed refresh as follows:
Response.AddHeader("REFRESH","3;URL=test.aspx");
However, I've now installed ASP.NET AJAX and have put the submit button into an UpdatePanel which gets the callback via AJAX and displays the information to the user. This is all done in the login.aspx.vb code behind file.
The timed refresh no longer works. I assume this is because I am doing a partial refresh and therefore adding a header to the page won't work... I assume
Is there any other way of doing this without adding more Javascript?
You will have to add some JavaScript to perform the page refresh. You assumed correctly; the page header to refresh will not work if you're only doing a partial update. If you register a client script in your postback to do the refresh, that should work OK.
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 have a JavaScript function that is manually calling a postback: __doPostBack('ctl00$searchButton', '');
The above searchButton is on a Master page and has an onclick event wired up. At the end of the event, I am re-directing to another page. This re-direct fails when the postback is called from JS. It works properly when the onclick is fired normally. I'm moving away from the auto fire in order to perform some client-side operations that are drastically reducing the HTML mark-up. I have tried replacing the Response.Redirect with a Server.Transfer with no success.
Any ideas here?
I suggest starting a debugging session and setting a breakpoint on that pages Load() method and seeing what the execution path is.
Also, try an HTTP proxy (HttpFox for FireFox plugin, Charles Proxy for an OS level proxy) to see what exactly the redirects are doing.