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.
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 am a beginner to .NET, I have some doubts in my mind. Can anybody help me to sort out?
When a user requests for a file(*.ASPX), The request first goes to IIS server and with the help of Handlers and modules it finds the type of file that need to be processed and sent back to the client. But while displaying on the cilent machine the content of the .ASPX file will be displayed as HTML controls. How are the events generated at the client side and sent back to the server?
I know runat=server tells the control will be processed at serverside.
But every time why we need to write "runat=server". Is there any ASP.NET control which runs at client side?
When you tell a "tag" to runat="server", you tell the server to register the tag. Now the tag is included in the control/tag tree on the server, and can be found ont the server: When an event is fired, or attributes or contents is changed server side.
Client side events, are silently converted to a form POST. Together with some extra information, like the ID of the control, and the type of event.
Since your tag is registered on the server, it has an ID, that is also transferred to the client (look at the html source). This tree is build, (by parsing the .aspx file) before the event is "fired". Using this id, you can find the tag in the server-side control/tag tree, and run the method that is used to handle the event.
Using these technique, and a lot of ViewState, Asp.Net tries to deny the stateless nature of HTTP. At first this looks like a good idea, IMHO its better not to fight with nature. Currently ASP.Net MVC feels more naturally.
if you are starting with .NET web development, ASP.NET MVC is the way to go IMO
an ASP.NET server control that is generating client events in the browser is exercising standard dom events via javascript code that gets injected into the page that is sent from the web server. try view page source from any browser to see what is actually generated and the picture will become more clear.
essentially runat=server is telling the ASP.NET parser to process the tag and generate some special HTML output for the page. see GvS's explanation in this thread of how client events for these controls are converted to a form POST that is handled on the server.
http://www.w3schools.com/aspnet/aspnet_intro.asp
How Does ASP.NET Work?
When a browser requests an HTML file, the server returns the file When
a browser requests an ASP.NET file, IIS passes the request to the
ASP.NET engine on the server The ASP.NET engine reads the file, line
by line, and executes the scripts in the file Finally, the ASP.NET
file is returned to the browser as plain HTML
also see
http://www.w3schools.com/aspnet/aspnet_controls.asp
http://www.w3schools.com/aspnet/aspnet_events.asp
These event just raised by server-side controllers ,when you click on a asp button , event information be captured on the client and an event message transmitted to the server, via an HTTP post.i think these possible by some registered event on the server.when you page is loading , some events registered on you page framework , and the raised by http post request.
Look, one of the difference between the client side and server side controls is the server side are registered in server and you can save their state in a view state for example. when you click on a server side button , first its client side event raised and the the server side .note that because the server side controls event registered on the server , when you click on the button ,you page posted back.but the client side controls just are valid in client , and their event just raised for you web browser
need more help ? comment me to edit my answer
regard , Ali
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.
What whould be the best way to prevent multiple users on a page?
For example if a user is at the page "Home.aspx", no other users should be allowed to go there.
I'm using asp.net on the server and the js-frameword jQuery on the client side.
The easy part is only allowing one user to access a page. You can for example store a session id in an application variable to keep track of who's on the page.
The hard part is to know when the user leaves the page. The HTTP protocol only handles requests, so the server only knows when a user enters the page. There is no concept of "being on" a page in the protocol.
You can use the onunload event in client code to catch when a user goes somewhere else, however this will not always work. If the user loses the internet connection, there is no way to communicate back to the server that the user leaves the page. If the browser or computer crashes, there will naturally be no onunload event.
You can keep requesting data from the server, by for example reloading an image on the page. That way the server can know if the user is still on the page at certain intervals. However, if the user loses the internet connection, the server will think that the user has left, while the user thinks that he/she is still on the page.
Another problem is browser history and cache. A user might leave the page, then go back to the page again. You have to make sure that the page is not cached, or the browser will just use the cached page and the server has no idea that the user thinks that he/she is on the page again.
Agreed with Guffa, you cannot be sure that the browser is already on the page or not, you can only check if the browser is already connected to that page or not.
You can do a sort of "ping", but its more a trick than a 100% working solution and it requires javascript enabled.
I didn't do it but I should look at XMLHTTPRequest and onreadystatechange to handle this :
1) On page load, the browser (client) initiate a XMLHTTPRequest with the web site (server) then wait for callback with the onreadystatechange event.
2) The web site receive the request and "mark" the page as "in use" with the current DateTime.Now.
3) Then the web site sends the response.
4) The onreadystatechange event get the response and the event code re-request the server to re-initiate the 2 after 1 min.
5) If another client request the page, the server check the DateTime mark : if the mark is greater than 1min ago, it means the client didnt respond to the request and may not be on the page again.
Not sure why you would want to do this because it flies in the face of web usability. You could do a locking mechanism on each page in server side code (write user name, page and time to a DB), which is freed up when they go to another page. You would then check on a the page load event to find out if anyone currently has that page locked. However, and this is a big however - have you considered what happens if somebody just shuts their browser down or walks off and leaves it on a page. You would need to seriously consider a timeout to free up locks too. That would need to be a back ground service, either in global.asax as global code or a separate process.
Maybe use static variables to hold the ip of the first user to access the page and then check whether other requests come from the same ip, otherwise display a "no access" page.
make sure you use lock it:
Object thisLock = new Object();
lock (thisLock)
{
// access static variables
}
You should also use "Session_End" method in global.asax to remove the ip address in case the user leaves your website without pressing the logout button
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.