i have a form where user enter some information. The problem is when they submit the form, due to session timeout, the page redirected to login page. After login they return to the same page but the form is empty and all information is lost which is very annoying for the user.
What is the best solution? I don't want to refresh the page. Should I send ajax request after every 5 minutes.
NOTE: The current Session Timeout is 40 minutes and it is stored in database.
If sliding expiration is enabled you could indeed poll the server at regular intervals to ensure that the session doesn't expire.
Pass the formcollection to the logon page to pass back to the form after redirecting.
EDIT: You can modify the action that the form posts to so that instead of sending unauthorized users to the logon action strait away you can have it first check if the user is authenticated then if not save the data somewhere (sql table or a cookie should be fine) and send the user to the logon action or continue to handle the data as normal. Have a parameter passed to the form action that indicates if and where to retrieve the saved data.
Related
I use session base authentication in my asp.net MVC website. Any time users that already using website will be logout in short time, cause of changing session id automatically, and it make trouble for them.
How can i stop session id changing?
in this pic you can see log of an user activities.
sql user loges
this problem happened when in any redirect of my website, redirect between "http://www.blabla" and "http://blabla". when change user URL requested, changed his session id and ...
i modify my code and use just "http://www.blabla" in my redirects.
I am using the Session object in my code to store the user login which will be saved to the DB.
I want to make sure about the the behavior on session timeout.
If the session times out what can the user do? I guess browsing to different pages does not restore the session? so only choice is to Close all of the browsers and come back in and Session gets alive?
I want to know under what conditions Session won't be alive again.
Also does Session time out fires the Session_End in the global.aspx?
A session is considered active as long as requests continue to be made
with the same SessionID value. If the time between requests for a
particular session exceeds the specified time-out value in minutes,
the session is considered expired. Reference
I believe that you are checking if the user is logged in or not in each page (or in masterpage), so as long as the user is not idle and he is using the system, the session will be updated and no worries.
If the user was idle for a long time and the session was expired, then it is logical to make him sign in again for security reasons.
use this on logout:
Session.Remove("sessionname");
I believe you're not explicitly killing the session by calling Abandon method on the session object in Session_End event.
Logging out of session makes this event to fire.And obviosly the user must be brought to the login page while trying to naviagte between pages.
Using the session to store a validated user's details is quite common. The session times out after a period of inactivity (I believe it's 20 minutes by default but can be changed in web.config.) This is usually desirable because if the user abandons the site (or walks away from their computer) without logging out it will kill (eventually) the session and effectively log them out automatically.
Reading or writing to the session will reset the timeout countdown. So if each web page check to see if the user is logged in all they will need to do if view a new page within 20 minutes and they won't be logged out.
If the user logs out (or the session times out) they don't need to close their browser, just go back to the login page and login again. So for each page that should be protected, check if their session exists and is logged in or else redirect them to the login page.
Yes the session timing out fires the session_end event.
We have a website that has a 20 minute session timeout and our users want a 10 minute session expiry warning. At the moment we're using a control which kinda does the job but it isn't AJAX aware and so pops up even if the user has been doing stuff.
I have an idea to get around this by just polling the server every 2 minutes to find out how long the user has left on their session. But after research i can not find out if its possible to say "This request shouldn't refresh the timeout", which is crucial as the act of polling would inadvertently refresh the session timeout.
Is this possible, or am I going about it the wrong way?
I think the only reliable way you can do this is to modify your ajax javascript to extend the timeout on your existing script.
You could use the disable session state for a page then modify your app to store the last access time for a user in the db. poll the session-less page to find out when the user last did something.
Either way you'll have to make extensive changes across your app.
If your session has a fixed 20 minute expiry, then it won't get extended by refreshing a page. However, if you want to have a script on your page to alert users of their imminent session expiry, then you'll need to set a client side script (presume Javascript) and kick it off on page load?
<script type="text/javascript">
function alertSessionTimeout(){ alert("Your session is about to expire. Please refresh the page.") }
window.setTimeout('alertSessionTimeout', 10*60*1000);
</script>
what about TWO web applications accessing the same database? in the first, the main, application you write last access time to database, and the second application is polled via ajax to get inactive time base on last access time...
In polling the server you see how long is left you would be resetting it back to 20 minutes. You would need to make sure the request does not attach the session cookie to prevent this. In doing so you create another problem in that you can't access the user session.
An alternative is just do in JavaScript page load using SetTimeout.
It seems that some people are confusing Session state with Forms Authentication ticket expiration. Session state has an automatic sliding expiration - if session is set for 20 minutes and after 19 minutes of talking to your friend in the office, you request a page, you get another 20 minutes.
This is an old question, but I have a similar problem and had this idea for a solution.
Upon each page request that uses the session, your session gets refreshed. Into the application cache, put key=sessionId and value=DateTime.Now.
Create a web service (.ashx or what have you) that does NOT use session state, but ideally is authenticated using Forms Authentication or some other authentication scheme. Your javascript, which is counting down the time until session expiration, will call this web service shortly before the session expires to see if the session is really going to expire.
I'm thinking the web service should return something simple like a 2 if the session is expired, 1 if the session is about to expire, or 0 if not. Return random [0,1,2] if the service is called by a user with an unknown or invalid SessionId cookie -- this would hopefully prevent valid sessionId discovery by an attacker who gets a Forms Auth cookie.
I investigated decompiling the built-in SessionProvider to see if I could access the session to discover the expiration without triggering a refresh. But doing so is dependent on the type of session provider being used, so if you ever move from, say, SQL Server session provider to Redis, you have to rewrite it.
Here's the scenario
I have a page lets say login.aspx having a button called login, on click event of that button when I check for the SessionID its shows a specific value for example "A"
Now I am making a call to some external page and that page then calls this page again.
for instance once I click login button I call a twitter app and when user authorizes it, I am redirected back to the same page, but now when I am accessing the SessionID its a new ID.
I have no idea why this is happening, I just want to have the same SessionID
Are you adding any data to the session? You need to do so for the session ID to "stick".
You don't have multiple web servers, do you?
If so, and if you're not using a shared session state provider, you'd tend to see this kind of behaviour.
Edit.
OK, next question...
Is the URL that the Twitter authorisation is returning to using exactly the same domain name?
For example, if your application is running on http://127.0.0.1:1234/ and the return URL is http://localhost:1234/ ?
Edit2: Yes?
When you are redirected back from the Twitter app on 127.0.0.1, the ASP.NET session cookie isn't being passed back to the web server because the domain is different.
You need the domain that the app is running under to match the Twitter callback URL.
Reconfigure the Twitter callback URL to localhost:1234 and I think you should be OK.
I have site that users lots of ajax(jquery). Now if the user times out for whatever reason(walked about for 30mins or something). On there next action I want them to be returned to the login page.
I setup everything in the webconfig(returnUrl and timeout) and if they try to go to a page they have no premission to go to they get sent to the login page.
However I have the authorize tags on the methods in my controllers that are used for ajax requests. So if a user timesout they are no longer authenticated but they might be on that needed authentication since they logged in and walked away.
Now they could go and try to save something at this point that would do an ajax request. The authorize tag will stop them from doing this since they will fail authorization and the return url will kick in.
However eventhough the return url seems to be sent back to them they are not redirected to the signin page. So I am guessing since all this stuff is ajax thats why it is not working properly. So is there away I can fix this?
You need to check the Ajax error for a 403 response
Run a client-side function every 30 seconds using setTimeout, which should ask the server via AJAX if the session has been timed out. If it has, the client-side code could toss out any login cookie and redirect to the login page.
You can either code hard-code the login url into the client-side code, or have the server handler return the value from the web.config if it needs to timeout.
This still leaves the possibility that the user could try something in the 0-30 seconds between when the user actually times out and the client side code does its request to check. To prevent this as well, have the server send back the amount of time left in the session, that way your client-side code can make the decision to either check back again sooner, or do the client-side redirect before the server-side drop-dead time.