Doing a browser refresh seems to create a new WebSession. Is this intended?
What is WebSession.Reloaded used for then?
Would you work around this by using cookies?
Some users may just hit refresh out of habit, I would like to have them come back already logged in if they were previously before the refresh.
Thanks in advance!
Yes, a browser refresh starts a new session. One approach to dealing with might be to create a “UserSession” class, keep an array of them in your app, set a cookie for a unique ID when a session starts, check for that cookie and a matching UserSession in Session.Open. You could then restore state such as the web page the user is on, etc.
This is stuff you have do though. It’s not built into the Web Edition framework.
-Brad
Where are you seeing WebSession.Reloaded?
Thanks Brad, good info. I was thinking of something like what you described if what I was seeing was true and intended behavior.
It would be nice if the Framework would handle that session reconnection if within a certain time frame, like a refresh.
Thanks again for the reply.
Best,
Steve
Hi Greg,
I haven’t seen it any where else, other than the docs… but though it might be a way to handle the session reconnection due to a browser refresh.
Best,
Steve
Can you be more specific? I’ve searched the documentation and can’t find a reference to the “Reloaded” event.
Search for WebSession.Reloaded, err, here is the link to it in the docs
From the description, I thought this might be a way around it.
Ah okay. That event no longer exists.
Please also update the help page for Websession.Quit. It says: “Ends the session. The user can still reconnect to the same session if they do so before the time specified in WebApplication.Timeout.”
May I ask why this was removed?
Seems like a good way to handle a refresh?
It was a leftover from the old way of loading pages.
When the web framework was new, going to a new webpage completely refreshed the browser, kinda like clicking a link. In 2011r2, we changed the framework so that webpage.show just pushed the new page down to the browser through the Ajax connection, thereby removing the need for a full refresh.
The second part of this puzzle has to do with how sessions are now created. In a normal web site, pointing two browser windows at the same site from the same browser, usually ends up with the windows sharing a session. For a web app, this ends up being a really bad thing because neither of them represents the whole state of the session. Our mechanism creates separate sessions for each window, so it becomes a bit more complicated to restore properly.
Gotcha Greg, thanks!
Is there a way to more gracefully deal with this?
Like can I capture that refresh was hit and ignore it?
The testers I’m working with now all keep hitting refresh (when they don’t need to) and it logs them out.
Suggestions?
So what needs updating about this? I thought this is how it works. I am using Websession.Quit in the Websession.TimedOut event.
[quote=110555:@Chris Halford]Is there a way to more gracefully deal with this?
Like can I capture that refresh was hit and ignore it?
The testers I’m working with now all keep hitting refresh (when they don’t need to) and it logs them out.
Suggestions?[/quote]
Will Cookies not help with this? I use cookies to log someone in if their name and hashed password are stored in a cookie.
WebSession.Quit closes the session and releases it from the list of active sessions. A user coming back to the app will be assigned a new session.
Keep in mind that if anyone looks at the user’s cookies, they will also have access to that user’s account.