Does the Web Browser holding onto Session Variables?

[Scholin]

I have a medical web app that is using the built in security and requires everyone to log in and will assign various __protected_session_variables. That all has been working just fine for over a year now.

However, there are a few places that have multiple users logging in at different times using the same computer. From time to time, they report having to either log in twice to gain entry or end up viewing data that was meant for the previous person who logged in last.

It seems like the browser must be holding previous session variables - I would guess.

So here is my question - Is there code I can add to the login or main page that will clear out any past variables to assure a clean log in each time?

Thanks, Mike

[Pat Bremkamp]

Re: Does the Web Browser holding onto Session Variables?

There are several settings to check.

For the login, go to the security configuration screen and check how the login expires setting is set. You might want to set a short time. I usually use "expires when user closes the browser", but that wouldn't work for several people using the same computer unless they are careful to close the browser after each use, and I don't think you can count on that. Maybe someone else will have a suggestion???

Second, go to the WAS configuration settings and see how long the session time is set for. Usually the default is 900 seconds, but the first thing users complain about is having to log in again too quickly. That's a balancing act.

Third, I've had no luck with logout pages. People tend to ignore them, so I put the logout code at the top of the login page. Again, I use a "belt and suspenders" approach and specifically delete certain session variables, then do a session reset, for example:

delete session.__protected__UserId
delete session.__protected__RealtorId
delete session.__protected__AgencyId
session.reset()

Pat

[Scholin]

Re: Does the Web Browser holding onto Session Variables?

Pat, this make a lot of sense.

I do have one question - The first page they come to when they open the website is of course index.a5w, which is the login screen - upon which takes you into the database - main.a5w screen.

I put the code on top of the main.a5w - above where the session variables are set, but that prevented them from setting so I moved it to the top of the index.a5w.

Seems thus far to work - that is, no errors. Is the 1st screen with the login dialog the correct page for this code?

Thanks again for your great advice!

Mike

[Steve Wood]

Re: Does the Web Browser holding onto Session Variables?

Probably what they are doing is opening a second browser window, while the first session is still active, or the first user did not log out properly. The second browser window will adopt any active session variables of the first window. Closing the browser does not close the session or remove session variables or log them off. Sessions have to expire. Even logging out does not expire the session, but it does remove the session variables IF you have session.reset() in your logout script. You can adjust Security Framework to log them out when they close the browser.

For the problems of too-short a session timeout, you can add javascript to the header of your page that fires an alert just before their session is about to expire and tells them to refresh their page or their session will expire. You see this with your online bank, it warns you your session is about to expire.

[Scholin]

Re: Does the Web Browser holding onto Session Variables?

Steve - I like the idea of the java script . . . but you know what the next question is . . . . so . . . do you have such a script??

[Steve Wood]

Re: Does the Web Browser holding onto Session Variables?

Yes, I do.

(Pink Panther)

[Steve Wood]

Re: Does the Web Browser holding onto Session Variables?

I had to go find it. So my server is set to 1 hour, and the alert to 55 minutes.

<script type="text/javascript">
setTimeout( 'ShowTimeoutWarning();', 3300000 );
</script>

<script type="text/javascript">
function ShowTimeoutWarning ()
{
window.alert("Your browser has been idle for 55 minutes. As a security precaution your session will end in five minutes. To continue, either refresh your browser or save your page. If your session has ended, you will have to log back in." );
}
</script>

You'd want this on every page, using a5w_include("header.a5w") or a5w_include("warningalert.a5w") or similar.

[Scholin]

Re: Does the Web Browser holding onto Session Variables?

Your da man Pink Panther! Thanks for sharing.

MIke

[Scholin]

Re: Does the Web Browser holding onto Session Variables?

Just as a follow up:

I am using Pat's suggestion of the session.reset() on my main page and Steve's JavaScript. I have to say, I think this really nails the problem.

The JavaScript is EXCELLENT - I was testing this out by leaving one of my web pages opened, exactly 55 minutes later WHILE I WAS IN ANOTHER APPLICATION, I was automatically pulled back to my web page with the warning waiting for me to hit OK. Very nice! There was no way for me to ignore it - exactly what is needed in my situation.

Thank you Pat and Steve - I appreciate your help and would highly recommend that people use these techniques in their web apps!

[Scholin]

Re: Does the Web Browser holding onto Session Variables?

Steve - I just had one more thought. Since the JavaScript is operating on the client side, can you see a way to enhance this a bit more by adding another timer action where by in 60 minutes (5 minutes after the warning) it automatically calls the logout screen or the login screen?

I noticed that even though my server sessions are set to 3600 seconds (one hour), I was still able to proceed using the database a fair amount of time after the hour of no use. I have code on every page checking for valid session variables as well but those sessions must not have expire.

So to be sure, it would be great if this could force the client page to go back to the login screen automatically.

I no nothing about JavaScripting and I am sure I could research this out but this feature is so good that I am sure others will be able to benefit from it going forward.

Thoughts?

[Steve Wood]

Re: Does the Web Browser holding onto Session Variables?

I am sure you can, and I will look later. I think you would keep the SAME javascript you already have but test when they click the OK button if the time had expired. If so, move to a different page. Actually, Security Framework should take care of that. If they are currently on a secuure page and try to refresh, it should take them to the logn page. But honestly sessions and logn 'sessions' are confusing to me too. i don't really know exactly what happens when one or the other expire.

[drgarytraub]

Re: Does the Web Browser holding onto Session Variables?

Coincidentally, I encountered the same issue just today. My office manager was logged in to the application and working with one data set, and then opened another instance of the browser, to login to a different data set. Well, just as Mike has pointed out, the New log in is being filtered by the former session variables. SO this thread is so timely.

However, I have put the code suggested by Pat at the very top of the index.a5w page, and it does not seem to kill the session variables. Here is the code that I put just below the <head> tag:

<%a5
delete session.pracid
delete session.userid
delete session.idnumber
session.reset()
a5ws_logoutuser()
%>

What am I doing wrong?

Gary

[Scholin]

Re: Does the Web Browser holding onto Session Variables?

I actually found the same thing - and even though my session lifetime is set to 3600 seconds, I find that I can go an entire day leaving the website open without any refreshes and still operate normally. I have all the above set.

However, on another computer I have - it all works fine as expected. Both computers have the exact same XP operating system with firefox as the browser. Not sure what the difference is and/or why the server session doesn't kill the web app after an hour.

I wonder if we could expand the JavaScript to clear out the browser and force the browser to a login page, if that would cure this problem?

[drgarytraub]

Re: Does the Web Browser holding onto Session Variables?

Hi Mike,

I hope as you do that there is a cure for this issue. It could really cause problems.

Gary

[Steve Wood]

Re: Does the Web Browser holding onto Session Variables?

You're not thinking correctly about sessions.

If you leave your browser open and the session expires, all session variables that YOU created will be deleted along with the session folder and its contents.

As soon as you refresh your page a new session folder will be created with the same name as the old one. Your session ID will NEVER have expired. It is not deleted when the session expires. It is retained in a cookie on your computer. Even closing the browser does not delete the session ID.
You won't notice anything at all UNLESS your application needed a value in a session variable that YOU created, but that is not repopulated when they refresh their browser. At that point it will either prompt a 500 error if you did not trap it, or follow your error trapping routine. The only way to delete the sessionID is with session.reset() (or to purge your cookies).

Logging out and session expiration are two different things. If you want your application to not operate when the session expires, you have to tell Security Framework to log the user out when the session expires (or after some period of time). If you tell Security to log them out when the browser closes, and they never close the browser, they are never logged out. If you include the RememberMe option, they stay logged in indefinitely (depending on your setting for that feature) unless they actually click Logout.

If you want your LOGIN to expire after a given amount of time, set that in Web Security Configuration.

-----

One way to test this out is to create a page that just shows your sessionID:

?session.sessionID

Bring up your session folders in file explorer and look for a folder with that name. Wait the appropriate amount of time and the folder will be deleted. Refresh your browser, it will be recreated. If you test, be sure to set your server for at least 5 minutes. Under that it acts like it is set to an infinite amount of time.