Bug #24125: jumpurl secure links over HTTPS fail in Internet Explorer when BE user logged in - TYPO3 Core - TYPO3 Forge

Custom queries

12 LTS
Accessibility
Dashboard issues
Easy tasks
Extbase Issues
FAL Issues
FAL Sprint 2023
Hierarchical Issues
Issues reported for v11
JavaScript issues
JavaScript Issues (w/o Epics/Stories)
Most wanted Bugfixes
Most wanted Features
My open issues
New & Unassigned
No feedback within 90 days
Open Bugs
Open issues of 10
Page Tree Regressions after 2020-07-28
Recently modified
Regressions
Stabilization Issues
Usability or UX

Watchers (2)

Alexander Stehlik
Thorsten Kahler

Actions

Copy link

Bug #24125

closed

jumpurl secure links over HTTPS fail in Internet Explorer when BE user logged in

Added by Alexander Stehlik over 13 years ago. Updated over 5 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Thorsten Kahler

Category:

Frontend

Target version:

Start date:

2010-11-18

Due date:

% Done:

100%

Estimated time:

TYPO3 Version:

4.4

PHP Version:

5.2

Tags:

Complexity:

medium

Is Regression:

Sprint Focus:

Description

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:

header('Pragma: no-cache');

There are two possible solutions:

The first would be to send out a new header in tslib_fe->jumpUrl if connection is HTTPS:
header('Pragma: private');

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)

Files

typo3-16466b-jumpurl_ssl-v2.diff (1.09 KB) typo3-16466b-jumpurl_ssl-v2.diff

Administrator Admin, 2011-02-04 11:56

Related issues 2 (0 open — 2 closed)

Related to TYPO3 Core - Story #28743: Add method to send no-cache HTTP headers

Rejected

2011-08-04

Actions

Related to TYPO3 Core - Task #90601: Remove old IE https download related hack in AbstractUserAuthentication

Rejected

2020-02-29

Actions

Issue # Delay: days Cancel

History
Notes
Property changes
Associated revisions

Actions

Copy link

Updated by Alexander Stehlik about 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:
Cache-Control: no-cache

The problem is known by microsoft and there is a hot fix for it that seems to work (tested with IE8):
http://support.microsoft.com/kb/323308/en-us

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.

Actions

Copy link

Updated by Mr. Hudson about 13 years ago

Patch set 1 of change I9ebe84174256263b8b0cae6cf9db58da76985a96 has been pushed to the review server.
It is available at http://review.typo3.org/1417

Actions

Copy link

Updated by Mr. Hudson about 13 years ago

Patch set 2 of change I9ebe84174256263b8b0cae6cf9db58da76985a96 has been pushed to the review server.
It is available at http://review.typo3.org/1417

Actions

Copy link

Updated by Mr. Hudson almost 13 years ago

Patch set 3 of change I9ebe84174256263b8b0cae6cf9db58da76985a96 has been pushed to the review server.
It is available at http://review.typo3.org/1417

Actions

Copy link

Updated by Alexander Stehlik over 12 years ago

Target version deleted (0)

During testing I realized something else. There is a PHP setting (which seems to be default in Ubuntu), that is called

session.cache_limiter

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: