Log in issue with 4.12.1
Added by Mark Travis about 2 months ago
I just tracked down the source of a puzzling refusal of my Wt application to let me log in.
I need to set to false in wt_config.xml to keep my users from killing what may be long math operation among other things. As a result, there are times when they log off the system (or time out based on idle time-out) and they are left at the log in screen.
Unfortunately, that log in screen at this point contains the ?wtd= signature from the prior session. It used to be that I could tell my beta user to hit refresh and log in again. Now I can't do that. They'll have to log in from a different tab, or highlight the ?wtd= portion of the URL and delete it before they can log in.
https://redmine.emweb.be/issues/13970 was released in 4.12.1 which I'm pretty sure is causing this new behavior and I understand and accept the reasoning behind it.
My question now is how to handle my scenario more elegantly. A reload that logs them off (loads new session) isn't going to be a good user experience.
Replies (4)
RE: Log in issue with 4.12.1 - Added by Matthias Van Ceulebroeck about 2 months ago
Hello Mark,
I'm sorry to hear that improvement has an effect on you. I didn't imagine a case where the user would be redirected to a page where the wtd parameter would be added to the browser's URL. Normally this is only handled by the framework.
I did overlook the case of reload-is-new-session being false it seems, after timeout.
As a sanity check, this issue only occurs when the client has reached its timeout, right, and their sessions has already been killed.
Otherwise I expect the session to be refreshed.
If you can change the value of reload-is-new-session to true that would resolve your issue. If that is not an option, please let me know.
Best,
Matthias
RE: Log in issue with 4.12.1 - Added by Mark Travis about 2 months ago
Yes, changing the value of reload-is-new-session to true does resolve that particular issue. And I don't mind a user hitting refresh and getting logged off. I doubt they would do that as I've gone to great length to make sure the UI is instantaneous or puts up an indication like a progress bar if something needs some extra time to load.
However, if a user hits the back button, then realizes they screwed up and they hit the forward button, they are presented with a login screen. This is a huge problem. Let me explain.
My target audience consists of high-strung analytics types. They like to get into arguments over the statistical results and they like to navigate down to a particular page of formulas or stats to prove their point. If the discussion involves navigating to another page of stats to continue to prove a point and they accidentally hit the back button instead of choosing an item from the left hand menu they will get logged off since the session will now reload.
Guess who is going to feel the brunt of their frustration?
Now, my current audience consists of two analytics types who are my partners trying to get this to market. So, not quite representative, but they've both unleashed on me for this in the past.
I wish I could just hide the browser back and forward button, which might take care of it, but I haven't found a formal way to do that, only javascript "hacks" which isn't acceptable.
RE: Log in issue with 4.12.1 - Added by Mark Travis about 2 months ago
Having this issue made me relook at everything, including the outdated instructions in the Wiki (https://redmine.emweb.be/projects/wt/wiki/Tips_and_Tricks)
I looked again at the javascript hacks and found one that might be a good work-around.
In wt_config.xml in the head-matter section, I included the following block:
<script type = "text/javascript" >
window.history.pushState(null, null, window.location.href);
window.onpopstate = function () {
window.history.go(1);
};
</script>
So far, this one seems to be working. But I need to research what it's doing in-depth to make sure I'm not shooting myself in my future foot.
RE: Log in issue with 4.12.1 - Added by Matthias Van Ceulebroeck about 2 months ago
Are you able to consistently rely on cookies?
That way, if the login page shows up again, you can call processEnvironment(), to log them in "automatically".
Disabling the back and forth functionality is not really supported on most browsers. As for the work-around. It should be fine, but I'd always be careful with changing history state.