Bug #31908

Cache does incorrectly cache previewed pages

Added by Stefan no-lastname-given about 10 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Must have
Assignee:
-
Category:
Caching
Target version:
-
Start date:
2011-11-18
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.4
PHP Version:
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

We have a large site with multiple domains and a single ssl certificate. The Backend is ssl protected, the Frontend without ssl.
When an editor previews a page in Typo3 it is served using ssl and added to the Typo3 cache containing links to e.g. images or js linked with https://..
When this page is then served on the Frontend it is taken from the cache and still contains those https links. Since the Frontend page is served from a different domain, the Browser generates a corresponding error: Bad certificate.
The page should not contain any ssl links.

A workaround is to clear the Typo3 cache, this is error prone since easily forgotten.

#1

Updated by Dmitry Dulepov about 10 years ago

You can use config.absRefPrefix or config.baseUrl with a proper schema. TYPO3 has no way to determine reliably when the site is http or https. So you have to tell that directly. Some pages can be forced to http or https but that does not apply to subpages. The only we can fix is that forced http/https.

#2

Updated by Stefan no-lastname-given about 10 years ago

We are using config.baseUrl, this does not help though. The preview link in the backend starts with https:// regardless of the baseUrl.
It must be possible to recognize a "preview" request from the backend and add accordingly: for instance not cache the page if it is a preview request, or delete it afterwards from the cache.
http://old.nabble.com/HTTPS-Backend--%3E-HTTP-Frontend-td32493228.html
discusses the same problem, unfortunately in German.
A different approach might be to correctly generate the preview link in the backend, it should not be https if the actual site is not running on https.

#3

Updated by Philipp Gampe over 8 years ago

  • Status changed from New to Needs Feedback

Do you have a domain record set?

Please try to set absRefPrefix in favor of baseUrl. Does it work then?

#4

Updated by Stefan no-lastname-given over 8 years ago

Yes we do have a public DNS Entry.

We can not set absRefPrefix since it does not work with realurl:

----
There is a TypoScript-setup directive to set an absolute prefix to all links and images (config.absRefPrefix), but sadly enough that isn't implemented in all places (the indexed-search and front-end-editing for example), so that doesn't work too well.
Please don't use config.absRefPrefix. It has some nasty properties that render RealURLs complete unusable sometimes. The only problem is that the 404-page of TYPO3 doesn't have the <base>-tag, so it doesn't show the TYPO3-logo Support for this might be allowed when the bugs are fixed but generally it will require all code generating reference to use this method and that cannot be guaranteed for all extensions of course.
----

Stefan

#5

Updated by Philipp Gampe over 8 years ago

config.absRefPrefix does work with realurl and Dmitry (the maintainer) even recommends it.
Can you please tell me the chapter of the realurl manual that you copied the above paragraph from?

#6

Updated by Philipp Gampe over 8 years ago

With domain record, I meant the record inside TYPO3 CMS.

#7

Updated by Stefan no-lastname-given over 8 years ago

Yeah we do set domain records for every domain we use (It is a rather large site).

http://wiki.typo3.org/Realurl/manual#config.absRefPrefix

#8

Updated by Philipp Gampe over 8 years ago

Maybe you should use the real manual and not some version by random people in the wiki.
http://docs.typo3.org/typo3cms/extensions/realurl/1.12.6/#config-absrefprefix

Hint: Never trust contents in a wiki!

Anyway, can you please try if this work for your now?

#9

Updated by Stefan no-lastname-given over 8 years ago

We tried it and I can confirm that it does work. So you were right, the wiki was outdated. This is sometimes hard to see then googling for a solution.
Thanks !

#10

Updated by Stefan Neufeind over 8 years ago

  • Status changed from Needs Feedback to Resolved

Thanks for the feedback.

#11

Updated by Benni Mack over 3 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF