TYPO3 Core

Might be related to #21511.
Possible solutions in #21511.
Might be something like #2151138.

This is always the case. It is not happening randomly. Actually can't login at all into Backend with IE. Itried also to play with IE8 compatibility settings, but this didn't change anything. It was the case with typo3 4.3 already, so not special to 4.4, but I hoped it would solved with it.

Is there something I could do to find out the cause. If I get some hints on where to set breakpoint either in php or in javascript module I could try to do some debugging.

Did you delete all cookies?

Not 100% sure, but I deleted all the cookies I found.
As far as I have understood similar problems it seems to be related to session cookies which the IE8 does not persist anyhow? Well I wasn't able to find any typo3 cookie from backend-login so not sure if one was created at all.

Didn't have a look at the other bugs, but there's the problem that IE8's Normal mode doesn't share cookies with Compatibilty mode - that's why you get logged off, while switching between modes. But that can only happen while switching.

This is happening to me in Firefox, Chrome and Safari in 4.4. When I login to the backend the expiration pop-up happens and it then just logs you out. Is there any way to resolve this? I can't get in the backend.

Ok, I'm not sure what I did. But it seems to work on my Macbook Pro (Which it didn't before) When I switch to any of my other computer. I still am having the same error.

Eckard,

could you please check if the user-agent-string of a normal get request is the same as the user-agent-string during an ajax-request?

Then it could be related to #22336

Hi, not sure if I have the right answer. I have httpwatch and on the login page I get
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR ...; .NET CLR 2.0.50727; MSN OptimizedIE8;ENUS)
that is the same as when I call other pages.
Would need some more hints on how to find out how to get user-agent-string during an ajax-request and a normal request.
Best regards
Eckard.

Please open another website where an ajax-request is done. For example

http://www.ffn.de/mediathek/party-bilder.html (click on one of the listed images)

Track the ajax request with httpwatch and post the submittet user agent. Thanks

I just created a better testpage. Hopefully it works. If any problem occurs, please tell me.

http://www.flagbit.de/test/user_agent.php

Hi Frederic,

I tried your page and I got two different results:

User Agent Get Request
Mozilla/4.0 (compatible; .... ;ENUS) chromeframe/6.0.472.51

User Agent Ajax Request
Mozilla/4.0 (compatible; ... ;ENUS)

I have noticed that before that there was this "chromeframe/6.0.472.51" in a difference but coudn't track it, when this is added or not.

Interesting enough I tried your page for google chrome:

User Agent Get Request
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.99 Safari/533.4

User Agent Ajax Request
new Ajax.Request('http://www.flagbit.de/test/user_agent.php?ajax=1', { method: 'get', onSuccess: function (transport) { $('ajax-p').update(transport.responseText); } });

and finally Firefox there is no difference:
User Agent Get Request
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)
User Agent Ajax Request
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 (.NET CLR 3.5.30729)

Maybe that is the reason why it works for me with firefox.

Best regards
Eckard.

Hi Eckard,

thanks for your feedback. There was an html error in my testpage causing Chrome to write out the javascript-code instead of executing it. I fixed it so you can test this in chrome if you'd like.

It is exactly as I suspected. Different user agents for ajax and normal request. Currently this is not allowed inside the TYPO3 backend due to security reasons. So this is mainly a duplicate of #22336 and can be closed.

By the way, the error is not really a fault of TYPO3 but it's caused by bad programmed plugins and themes for the Internet Explorer. The best would be to use the firefox inside the backend. Sorry.

Best regards,
Frederic

If there are browsers out there, we must IMHO get rid of the locking to the UA string.

If there are browsers out there with this behavior, we must IMHO get rid of the locking to the UA string.

Read through #22336, seems like duplicate, so set to resolved. Please continue there / in the dev list.