[TYPO3-english] fe users and caching

Simon Browning simon at seethroughweb.com
Sat Jun 23 22:18:19 CEST 2012


You're right, I mixed the two up (end of a long day/week).

I've not encountered the problem before either, however my client is 
reporting that she's not seeing secured pages in the menu after logging 
in, though she is seeing secured content on the page.

I'll have to fiddle with it.

Simon

On 12-06-22 5:17 PM, Loek Hilgersom wrote:
> Hi Simon,
>
> You're confusing browser cache (client side) with TYPO3 cache (server
> side). The no_cache=1 option (at least the Typoscript one) is the server
> side TYPO3 cache which has nothing to do with the browser cache.
> On the server side, TYPO3 will take care of serving a different page -
> provided there is any restricted content - when a user logs in. On the
> client side the browser should do the same, I never encountered any
> problems with that. So why don't you first try it before bringing up
> hypothetical questions?
>
> If there would be any problems with unintended client-side caching you
> can tweak the http-headers and include the 'no-cache' flag.
>
> Loek
>
>
> On 22-06-12 21:50, Simon Browning wrote:
>> A question came up today to which I'm not sure of the answer.
>>
>> How can we be sure that when a front end user logs in that he/she sees
>> front end
>> secured items, and they don't get fooled by browser caching?
>>
>> Example 1 would be a page that is only available in the front end to
>> logged in
>> users.
>>
>> Example 2 would be page content that is only available to logged end
>> users (so a
>> regular page that has content on it that is restricted and only shows
>> up on login).
>>
>> Could it be possible that the user logs in and doesn't see the secured
>> items
>> until they clear their browser cache?
>>
>> How do we prevent this if it is possible. I know we could set
>> nocache=1 for
>> logged in users, but that seems like a fairly horrible solution.
>>
>> Thanks
>>
>> Simon
>




More information about the TYPO3-english mailing list