Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • typo3 typo3
  • Project information
    • Project information
    • Activity
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Insights
    • Repository
  • Activity
  • Graph
  • Jobs
  • Commits
Collapse sidebar
  • typo3typo3
  • typo3typo3
  • Repository
Switch branch/tag
  • typo3
  • typo3
  • sysext
  • frontend
  • Classes
  • Middleware
  • FrontendUserAuthenticator.php
Find file BlameHistoryPermalink
  • Benni Mack's avatar
    [!!!][FEATURE] Always initialize frontend groups after FE user · ee7667f5
    Benni Mack authored Oct 07, 2020 and Christian Kuhn's avatar Christian Kuhn committed Oct 19, 2020
    In previous TYPO3 versions (due to historic reasons) the frontend
    groups were always resolved within TSFE when a page and the
    rootline was resolved.
    
    However, this left the actual Frontend User, which is initialized
    at the very beginning of a frontend request, in an incomplete state:
    A user was (correctly) found and "logged in", but the groups were
    resolved at a later point.
    
    This was due to the fact that the Admin Panel allowed to
    "include hidden records" which also considered fe_groups,
    and thus be set later-on.
    
    This change now moved the resolving of the groups (and setting
    the right frontend.user aspect) right after the user resolving.
    
    This means that the groups are now available much earlier, and not
    bound to the TSFE instance anymore, allowing to use Middlewares much
    more professionally without depending on TSFE for custom Routing / APIs.
    
    Future options:
    It would even be possible to filter out PageRouter pages that are
    not available, which would make the Router itself faster.
    
    Resolves: #92562
    Releases: master
    Change-Id: Ia522697433049b0e549f3c65caf6757053ff37e1
    Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/66066
    
    
    Tested-by: default avatarTYPO3com <noreply@typo3.com>
    Tested-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
    Tested-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
    Reviewed-by: Markus Klein's avatarMarkus Klein <markus.klein@typo3.org>
    Reviewed-by: Anja Leichsenring's avatarAnja Leichsenring <aleichsenring@ab-softlab.de>
    Reviewed-by: Christian Kuhn's avatarChristian Kuhn <lolli@schwarzbu.ch>
    ee7667f5