Sporadic random Backend Logoffs
I have been informed by one of our customers, that he is being logged off shortly after login, or while trying to edit content elements on a page.
(issue imported from #M11968)
#3 Updated by Steffen Gebert over 10 years ago
Is he using a dial-up connection with a short timeout?
T-Com router have a senseless short connection timeout time of a few minutes.
Especially this sounds reasonable for "or while trying to edit content elements on a page.", if he needs 10min to write his text or grabs a coffee in between.
#5 Updated by Ernesto Baschny over 10 years ago
Then probably the company goes out through multiple IPs (proxy) and the backend is fixed for a session on a single IP. Analyse your Webserver logs if you see the same session coming from two different IPs, it is not a bug, but a setting you can make:
$TYPO3_CONF_VARS['BE']['lockIP'] = '3';
#10 Updated by Steffen Gebert over 10 years ago
I had two clients in my last training, which used IE8 and were sometimes thrown out of backend. We added the site to the trusted sites and think then only one was thrown out once.
I just tried IE8 and got quite quick thrown out, with the hint that IE switched to compatibility mode.. but as I'm now in this, it shouldn't throw me out again (question: why switches IE8 to compatibility mode??).
I'll try to use IE8 the next days to test it a bit.
#11 Updated by Ernesto Baschny over 10 years ago
I tested some minutes with IE8 and couldn't reproduce that.
I was only "thrown out" of the backend as soon as I clicked on that "compatibility mode" icon that is being displayed besides the address bar. Maybe people are just hitting this button thinking that it will reload the page? The reload button is just on side of that. See screenshot.
Why the "compatibility button" resets the session I don't know, but you might try to simply tell people not to hit that button?
#12 Updated by Steffen Gebert over 10 years ago
No, they for sure didn't hit that button.
I always get switched to Comp-mode, as soon as I open the page properties using the click-menu in the page tree.
I think it's a new session b/c a IE7 is loaded internally (which seems not to share the session data).
I found no way to get an error log shown and the developer tools weren't modernized since ages. Anybody an idea, how to get information, why IE switches?
#13 Updated by Ernesto Baschny over 10 years ago
It has been documented on how to get rid of the "compatibility switch" on a website. Read the full blown explanation and history of it here: http://www.alistapart.com/articles/beyonddoctype/
To sum up, if we add this header:
<meta http-equiv="X-UA-Compatible" content="IE=8" />
we are saying "IE8 in standards mode please" and then no switch is presented to the user anymore. See attached patch which adds this and try it out.
#15 Updated by Ernesto Baschny over 10 years ago
IE8 displays that buttoon on every page that is presenting itself in standards mode and has no meta-tag. This is not an error message, but the intended behaviour (allowing the user to switch the mode when the page author hasn't really specifying the target browser).
If you are not used to see this toolbar icon it is because most major sites either already have this meta tag "X-UA-Compatible" in their headers (facebook, web.de, spiegel.de etc) or they have no indication of wanting standards mode (e.g. invalid xhtml, no DOCTYPE, etc).
Since TYPO3 presents itself as "standards valid xhtml" but doesn't say which IE version it targets, that IE7-compatibility button is shown.
Adding the meta-tag will solve the problem.
If your Backend is switching back and forth the IE8 + IE7-mode, it might come from extensions that provide invalid markup or something that makes IE switch a sub-frame into quirck mode. That is just an assumption, don't know if this is really the problem.
#16 Updated by Ernesto Baschny over 10 years ago
And another note about this, just found this piece of information, which might explain why setting the TYPO3 backend in the "trusted" zone alleviates the problem:
"A large number of line-of-business websites are Internet Explorer 7 capable today. In order to preserve compatibility, Internet Explorer 8 ships with smart defaults based on zone evaluation. In the default state, all sites on the public internet display in Internet Explorer 8 Standards mode (Compatibility View off) and all intranet websites display in Internet Explorer 7 Standards mode (Compatibility View on). "
#18 Updated by oliver leitner over 10 years ago
thank you very much for checking this up.
adding the new meta tag indeed fixed the problem for the customer it seems.
the patch of course is not for the current 4.1, i think this is 4.2 code, however, i put in the code myself by hand, and the customer has not yet been logged off.
#21 Updated by Ralf Hettinger over 10 years ago
As from my observation, I can confirm that X-UA-Compatible meta tag solves a lot (all?) of the problems for logins getting invalid... so a +1 for introducing this for the moment (hopefully IE >= 9 won't choke on this one).
Maybe it would be a good idea to have some extra config option for the frontend (ie tslib_pagegen) as well, since as for the moment the only thing that works without hacking the core is to set
<meta http-equiv="X-UA-Compatible" content="IE=8" />
since IE8 expects the meta tag at the very beginning of the page.
But this is another topic of course.
#26 Updated by oliver leitner over 10 years ago
the bug is not fixed yet.
the user has not confirmed me that the change solves his problem, currently i am in wait state, as soon as i know more, i will inform you.
on a side note, adding the htaccess information seems to break other parts of the homepage, namely kj_imagelightbox
#28 Updated by oliver leitner over 10 years ago
the idea behind setting the htaccess value was, that customer doesnt have to change things in his/her ie8, and the page itself decides.
the customer is not the kind of person, that knows howto use a webbrowser.
#30 Updated by Jo Hasenau over 10 years ago
logouts do happen in IE8 with current 4.3 trunk as well
i.e After logging in a click on an click menu icon in the page tree and then on "edit" lead to a logout
After logging in a second time the same procedure worked without logout
Seems there is a problem with session handling between different URLs in frames or something like that.
#33 Updated by Ernesto Baschny over 10 years ago
Maybe better test the ie8-force-strict.diff patch, which is what we would need to add to the core instead of a .htaccess switch which might affect much more than just the TYPO3 backend.
@JoH, could you test it, please? I couldn't reproduce it, yet.. :(
#35 Updated by Ernesto Baschny over 10 years ago
Steffen, could you be more "precise"? What is bad about this patch?
I cannot really follow your arguments as I am not sure where you are guessing, proposing a solution that might work, or provide a working solution. Do you know how to solve the problem already?
#36 Updated by Ernesto Baschny over 10 years ago
What I can say is that with this patch the "compatibility switch button" is gone unter IE8 and TYPO3 backend. If this avois the logoff problem or is just of cosmetical nature, either way I think it is "good", as the compatibility switch button in IE8 being present in TYPO3 backend is already ugly.
#37 Updated by Steffen Gebert over 10 years ago
Sorry, I'm a bit harried today...
I remembered template.php.ie8_backend_logoff.diff, which is not a unified diff.
I can't reproduce the frequent logouts as they appear for oliver's client: As Jo, I login, do sth. and then get logged out, because IE switches to compatibility mode (=IE7).
IE7/8 seem to not share their cookie information, so the session is ended and user logged out.
If I force to use IE8-mode, everything worked for me. I hoped to find out, WHY IE switches, but couldn't find anything (thought of a JS error.. but nothing). So it seems to stay a mistery.
As IE8 mode seems not to have any problems with TYPO3 BE, I also think we should add the meta tag to TYPO3.
Of course, my advise to add the line to .htaccess was ment for testing purposes (and could also be added typo3/.htaccess :-P).
As you provided a patch for 4.3, I'd appreciate to have this and a 4.2 compatible one in core list.
Hope you understand my weird notions now :)
#38 Updated by Jo Hasenau over 10 years ago
The problem is that these logouts really happened randomly, so it is not easy to reproduce them with or without an active compatibility mode.
The only thing I can confirm is, that switching the mode manually will log you out immediately.
Adding a META tag could break stuff in other versions of IE though.
#39 Updated by Ernesto Baschny over 10 years ago
@JoH, "could break" what do you mean exactly? Previous version of IE didn't care (didn't even know) about this meta tag, future versions of IE will know that we aimed IE8 and act acordingly. So I see no problem whatsoever of backwards compatibility issues with this meta tag (which is why it was introduced in the first place).
If you run your system with my mentioned patch and it doesn't logout, it might be the solution and we should / could /must also apply this to TYPO3 v4.2 and v4.1.
@Steffen, thanks for explaining. still you haven't said if you think ie8-force-strict.diff "bad" or "good". It is unified, and yes, it is for trunk only (because it is still unproven that this is really related to the "logoff" problem). Attached is now also a patch for 4.2.
#40 Updated by Jo Hasenau over 10 years ago
Now I got one I was able to reproduce:
1. Login without activated compatibility mode
2. Go to Extension Manager
3. Switch to "Import Extensions"
3.a) If the Extension Manager already shows "Import Extensions" switch to "Install Extensions" and back to "Import Extensions"
This will always trigger the compatibility mode and logout immediately.
#42 Updated by Ernesto Baschny over 10 years ago
@JoH, not reproduceable here with 4.2.10.
I've had one "logoff" already but also cannot say what exactly was done (just switching from Page to List view as far as I remember). Very difficult to spot!
Maybe you could find something out if you really got it reproduceable on your system. Maybe try the ie-force-strict-42.diff patch to see if it helps?
#45 Updated by Steffen Gebert over 10 years ago
I call it "bad" because i think the way it is done, is bad. I haven't tried it, as I didn't know, to which version it applies.
Can you reproduce the problem with the patch applied? I think it doesn't switch, if the header/meta is present and so it should work.
Also it can't break any older version. For newer versions, the setting has to be adjusted. Back like in times of browser switches. Thanks M$.
#48 Updated by Ernesto Baschny over 10 years ago
@Steffen, what is "bad" about the way it is done? Can you suggest something better?
The MS-idea is that it doesn't need to be adjusted in newer versions. Newer versions of IE will know how to behave. It is like our good old "compatVersion" in TYPO3, which we added for the exact same purpose: make the rendering of a newer version "behave" like an older version. So I see no flaw in the concept and it is much better than the previous fixes (switching xml-prologue etc). This was created in a collaboration of many CSS / XHTML specialists and MS. See http://www.alistapart.com/articles/beyonddoctype/
So maybe you are just biased by previous MS-oddities which might mislead your judgement on the matter.
For our TYPO3 backend it should mean:
If we know that our backend works in IE8, we "tag" it as such in this meta tag and also future IE versions will know about it without "breaking" our site. Because IE8 can also emulate IE7, we might even tag ourselves for IE7 so IE8 will know about it.
#49 Updated by Jo Hasenau over 10 years ago
After all it seems I found the reason, why in the case I was able to reproduce IE8 switched to compatibility mode:
After replacing any & with & before using window.location.href, the switch didn't happen anymore.
URL = URL.replace(/&/g,"&");
Since this removes a cause instead of the symptom, IMHO we should check if this could be a cause at other places as well.
Maybe the URL has to be formatted according to the doctype to avoid the switch? Then we will need an additional check. But first I would like you guys to check if you can confirm my observations
#51 Updated by Jo Hasenau over 10 years ago
Internet Options> Advanced> Browsing> uncheck "Automatically recover from page layout errors with Compatibility View."
This does prevent IE8 from switching to IE7 mode - but this means: There must be "page layout errors" recognized by IE8 that trigger this behaviour, which still leaves us with the problem that we have to find the cause.
#52 Updated by Steffen Gebert over 10 years ago
Sorry, but again the question: Does IE switch to compatibilty mode, if the X-UA-Compatible flag is set? Regardless of finding reasons for the switch, we have to add this flag because I'm 99% sure, we'll never find all the reasons, why it switches.
I hate this flag because as we see here, it results in trouble. Why does it not just act as IE8 and work closer to the standards and enough.
#55 Updated by Mark Möller-Bengtsson about 10 years ago
I've just dealt with a similar issue with a client of ours.
The problem, in our case, occured even between updates of IE (7->8).
Spent numerous of hours trying to figure it out and trying to replicate the issue and here's the deal:
For some reason Google Chrome Frame was installed and although it should not interfere unless told so specifically through <head> it does. It breaks IE7/8 (confirmed) and possibly IE6 aswell.
Should mention that the session timeout/random logoff occurs as soon as an AJAX-call is made.