TYPO3 Core

I have no idea how to solve this yet, so I'm just brainstorming for now...

Idea #1: Use "loginMode" flag to disable login information for a whole page.

Drawbacks: No personalized content is possible at all!

Considerations:
- I've made a patch already which can restore the login information for INT objects which are never cached anyways. However, this requires loading the full template (which is luckily stored in the cache, so it should not need to be re-parsed again).

Idea 2: Introduce new flag which indicates if a page needs personalization, authorization (on page level), or none of both.

The flag has a default value and can be changed by extensions (similar to $TSFE->set_no_cache()).

If none of both is needed, then the gr_list of the page in the cache is set to "0,-3" (todo: maybe "0" is enough?) which means: No page access check is needed.

If only authorization is needed, then the gr_list of the page in the cache is set to "0,-4" (or "0,-3", see above) which means "lookup page access again".

If personalization is needed, the old behaviour will be used ("0,-1" applies to no logged in users, "0,-2,<groups>" applies to any logged in users matchin all specified groups.

Drawbacks:
- complex
- not sure how good it will work

Hi Michael,

this is really a problem that e.g. for properuser access it has to be done with USER_INT to prevent this cached information. I don't have a real idea atm how to solve.

It would help if $TSFE->fe_user never be cached, but this is a complex thing. May be it's better to make this only instead of whole page method.

There were such a lot discussions about that and it's difficult to extract the essence out of it. Hope that a solution can be found.

We struggle with the same problems on several customer sites. On most we have chosen "custom" search solutions over indexed_search exactly because of this limitation.

Some ideas also occurred in our team to improve that (specifically for indexed_search, but maybe it also can be used generally). Basically it would mean that the admin has to tell the indexed/cacher more about its page tree structure and which type of fe_group usage he has. For example:

- Be able as an admin to specify which fe_groups are relevant for a certain page tree. So saying in a certain page tree: only consider group "-1" (anonymous) and "2" (fullaccess), the cacher/indexed wouldn't care if the user is also in group 1, 3, 4 or whatever. We will always have maximum 2 cached entries and 2 indexed-search variants for any phash on that tree.

- Maybe it can help if we could say (in TypoScript for a specific page tree again): We don't use "user-specific content elements" in this page tree. So please just cache and index pages as a whole if the user has access to the page at all.

What we also usually require is a "fulltext search" that is able to scan the complete fulltext database without regarding gr_list at all. If the admin likes and configures it to be so the search form in "indexed search" will always find every content on the site (and never show "different" results for different user groups). When following the link will then either don't show the content or redirect to a login page instead or whatever. Some more complex configuration on that matter could "fine-tune" that behaviour (like a list of fe_group uid's to always include in the fulltext search results).

Also about the gr_list problematic there must be an easy way to "crawl" the whole site with different permissions settings. Is there? Using "crawler" I couldn't find an "easy" way to do it.

Well, so far for the "brainstorming"... :) Maybe some of the ideas here are not implementable at all, maybe they are.

this is related to #0005510 and #0004286

Is there somewhere a documentation what 0,-2,-1 etc. means?

@Jonas: 0,-1 means logged out. 0,-2 means logged in. The rest of that string contains the list of the usergroups.

My idea to solve this problem:
- we save for which user groups this view is used instead of which user groups the user had who view this.
- this may collide with plugins which depends on the yet existing handling of the caching.

Examples of how it should work, to see if this is manageable:

On write
Page Access + User        => Access List
No FE Groups              =>  0
         -1 + 0, -1       => -1
         -2 + 0, -2       => -2
          2 + 0, -2, 2    =>  2
       2, 3 + 0, -2, 2, 3 => 2, 3

On Read
Access List + User         => read/no access
          0 + No FE Groups => read
         -1 + 0, -1        => read
         -1 + 0, -2        => no access
         -2 + 0, -2        => read
         -2 + 0, -2, 2, 3  => read
          2 + 0, -2, 2     => read
       2, 3 + 0, -2, 2     => no access
       2, 3 + 0, -2, 2, 3  => read

A page can now have different content elements with different user groups. Situation, one page have three content elements:
Element A: Show for logged out users (-1)
Element B: Show for logged in users (-2)
Element C: Show for users with fe_group 2
Element D: Show for users with fe_group 3

User        => positive Access List + negative Access List
0, -1       => -1                   + 
0, -2       => -2                   + 2, 3
0, -2, 2    =>  2                   + 3
0, -2, 2, 3 =>  2, 3                +
0, -2, 3    =>  3                   + 2

We need the negative list, cause for user "0, -2, 2, 3" we don't know if the cache entry with the positive Access List "2" is all he can get or do we need to generate a new page.

A page with content elements which have multiple user groups:
Element A: Show for users with fe_group 2 or 3
Element B: Show for users with fe_group 3 or 4

User        => positive Access List + negative Access List
0, -1       =>  0                   + 2, 3, 4
0, -2       =>  0                   + 2, 3, 4
0, -2, 2    =>  2                   + 3, 4
0, -2, 2, 3 =>  3                   +
0, -2, 3    =>  3                   +
0, -2, 4    =>  4                   + 2, 3
0, -2, 2, 4 =>  3                   +

=> So we get a maximum of 4 pages in Cache.

I would like to see an improvement in the gr_list stuff. If you have many different usergroups and combinations, its renders indexed_search useless, because you have to index for every combination. and this is exponential. thanks

@Susanne Category "Image Cropping" seems like a mistake to me. I would rather say that this is about caching...

@Susanne see my comment above (just added you as watcher to this issue).

Yes, Image Cropping was a mistake, thanks for paying attention :)

OK. This is my proposal:

• We should cache on "CE level" or "per entity" level. Because if a CE does not have any restrictions (fe_group), it should be "ALWAYS CACHED". This should be cached away, and fetched.
• When "0,-1" is called, it should be possible to fetch everything statically already and just put the pieces in.
• If a page itself has pages.fe_group set, we need to differentiate between "Is allowed" or "is not allowed".

Basically we work like a "firewall" for the cache. Yes, cached under these circumstances. CEs / Pages should be based on the content, not on the visitor!