jumpurl secure links over HTTPS fail in Internet Explorer when BE user logged in
There is a little bug in the jumpurl_secure feature. It may not affect many people but because it is very specific. To reproduce it, these conditions must be met:
- Filelinks with jumpurl_secure enabled
- connection is HTTPS
- browser is Internet Explorer (all Versions)
- Backend user is logged in
When clicking on a link the downloads fails with the following error message: "The requested site is either unavailable or cannot be found"
The reason for this problem can be found in the start() method of the t3lib_userAuth object. For BE users the property "sendNoCacheHeaders" is set to TRUE. This results in a bunch of headers that are sent out to the client. This is the one that let's the jumpURL link fail:
There are two possible solutions:
The first would be to send out a new header in tslib_fe->jumpUrl if connection is HTTPS:
Another solution would be to check in the t3lib_userAuth if the connection is HTTPS and then decide weather to user "no-cache" or "private".
If you let me know which solution you prefer I can provide a patch.
(issue imported from #M16466)
Updated by Alexander Stehlik almost 13 years ago
Important! If you want to test this bug you have to make sure, that gzip compression is disabled. Otherwise the error doesn't occur.
I realized, that there is another problem with another header:
The problem is known by microsoft and there is a hot fix for it that seems to work (tested with IE8):
As this bug seems to affect all IE Versions I think it should be fixed in TYPO3. I'll attach a patch that improves the header handling in t3lib_userAuth::start. The patch was tested with IE8, Firefox and Google Chrome.
Updated by Alexander Stehlik over 12 years ago
- Target version deleted (
During testing I realized something else. There is a PHP setting (which seems to be default in Ubuntu), that is called
If this is set to "nocache" (default setting on my system, Ubuntu 11.04) you will also get the error in the Internet Explorer if you use an HTTPS connection.
So when you test this please make sure this is set to an empty string in your php.ini:
Updated by Thorsten Kahler over 12 years ago
- Category deleted (
- Status changed from New to Under Review
- PHP Version changed from 5.3 to 5.2
- Complexity set to medium
I came across a similar problem (downloads over HTTPS in IE) (again) today. From what I found your general approach seems correct to me, the details can be discussed in Gerrit.