TYPO3.Flow

[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
  \TYPO3\Flow\Security\Context::separateActiveAndInactiveTokens()

• 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
  ways.

• 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
    REQUEST SET BEFORE.
  • 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->accessDecisionManager->decideOnResource('TYPO3_Neos_Backend_BackendController');
  • 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
implemented.

Change-Id: I724c1b352dd1807ba53b1e336f2d90e90360ff4d
Releases: master, 2.0

[BUGFIX] Fix security-related functional test failures

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing functional tests.

It does that by:

• changing the order in which security is set up in the
  FunctionalTestCase provided by Flow.
• setting the "current request" again after a call to clearContext() in
  ContentSecurityTest
• adjusting the expected exception in MethodSecurityTest in two places

Change-Id: I353e2cba11473cf9ddef82f96b6a79d9d6fefbba
Fixes: #44765
Related: #42601
Releases: master

[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
  \TYPO3\Flow\Security\Context::separateActiveAndInactiveTokens()

• 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
  ways.

• 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
    REQUEST SET BEFORE.
  • 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->accessDecisionManager->decideOnResource('TYPO3_Neos_Backend_BackendController');
  • 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
implemented.

Change-Id: I724c1b352dd1807ba53b1e336f2d90e90360ff4d
Releases: master, 2.0

[BUGFIX] Fix security-related functional test failures, part 2

The change I724c1b352dd1807ba53b1e336f2d90e90360ff4d introduced some
test failures. This change takes care of the failing functional tests.

It does that by:

• setting the "current request" again after a call to clearContext() in
  ContentSecurityTest
• adjusting the expected exception in MethodSecurityTest in two places

This is a followup to I353e2cba11473cf9ddef82f96b6a79d9d6fefbba which
was broken after having fixed those already.

Change-Id: I09182972baf668abbb2cf583e8deebdc31e90205
Related: #42601
Fixes: #44765
Releases: master, 2.0