« Previous | Next » 

Revision ce08c301


Added by Sebastian Kurfuerst almost 9 years ago

[BUGFIX] The security context is only allowed to be initialized after routing took place

This bugfix solves the root-cause for the following two symptoms:

  • two logins needed in Neos until the Site is shown
  • if the Flow_Mvc_Routing_FindMatchResults cache is deactivated completely,
    the login does not work at all.

The problem is as follows:

  • The security context needs the current request for working properly;
    such that it can separate the active and inactive tokens correctly in
  • The current request is built during routing. Thus, the routing mechanism
    (f.e. RoutePart handlers) is not allowed to access the Security Context
    in any way. If it does (like in this example), things might break in various
  • For Neos, the following call chain takes place:
    • Routing
    • FrontendNodeRoutePartHandler->matchValue line 51
    • NodeService->getNodeByContextNodePath() line 57
    • new ContentContext() calls "initializeObject"
    • ContentContext->initializeObject does $this->domainRepository->findByHost()
    • this internally uses Repository->findAll()
    • this executes the TYPO3\Flow\Security\Aspect\PersistenceQueryRewritingAspect->rewriteQomQuery
    • because Neos has policy entries for entities (TYPO3\TYPO3CR\Domain\Model\Node),
      $this->securityContext->initialize() is called, WITHOUT HAVING A
    • This results in a half- and wrongly-initialized Security Context
      set up, with activeTokens not properly set, and also only the
      standard roles assigned ("Everybody").
    • Thus, the check in TYPO3\Neos\Controller\Frontend\NodeController->showAction() fails:
    • This redirects the user back to the login ($this->redirect('index', 'Login'))
    • Now, if the routing cache is activated, the aspect kicks in (in
      the second iteration) and directly returns the match result, without
      triggering a database query before.

Thus, we need to enforce that the security context is not initialized during
the routing phase.

The attached patch is just a quick fix; with not really the clean solution.
But at least it works and the problem is properly described ;-)

This is a follow-up to issue #42601; where the according code has been

Change-Id: I724c1b352dd1807ba53b1e336f2d90e90360ff4d
Releases: master, 2.0

  • added
  • modified
  • copied
  • renamed
  • deleted