Bug #33055

AccessDeniedException instead of WebRedirect

Added by Patrick Pussar almost 10 years ago. Updated over 7 years ago.

Must have
Target version:
Start date:
Due date:
% Done:


Estimated time:
PHP Version:
Has patch:


After defining some restrictions via ACLs on a controller method and defining a WebRedirect I get an AccessDeniedException instead of a redirect.

After do some dirty hack in RequestDispatchingAspect.php:
//} catch (\TYPO3\FLOW3\Security\Exception\AuthenticationRequiredException $exception) { // PPUSSAR: Hot-Patch to get Web-Redirect working
} catch (\TYPO3\FLOW3\Security\Exception $exception) {

it works as expected.

Whether the catch method is to restrictive or the wrong exception is thrown.

Related issues

Related to TYPO3.Flow - Bug #33078: No Redirect to LoginNew2012-01-10


Updated by Johannes K almost 10 years ago

Did you try to call the protected action manually, or via a Fluid generated link?
I'm asking, because to call protected action you also need to pass a csrfToken in the URL.
If the link is generated by Fluid, the URL contains the csrfToken automatically.

Another option is to annotate the action with @FLOW3\SkipCsrfProtection.

No real documentation for this yet, but here is an explanation:


Updated by Patrick Pussar almost 10 years ago

It is the first call to the Site. Meaning a user calls a domain like: http://mydomain
This url is linked to a site, which is under ACL restriction. The idea is that the user becomes redirected to the login in case that he is not logged in or can see the content of the page in case that he is already authenticated.


Updated by Patrick Pussar over 9 years ago

The controller method is already annotated with @FLOW3\SkipCsrfProtection


Updated by Andreas Wolf almost 9 years ago

I can confirm this problem on latest Flow master. I think that either throwing an "AccessDeniedException" is wrong here or that the RequestDispatchingAspect should also redirect to the login form in case the access was denied.

As far as I understand the concept, "AccessDeniedException"s should be thrown when there is no hope that the user might gain access with a login, i.e. they are already logged in but don't have the neccessary permissions to view the requested resource.
OTOH, the "AuthenticationRequiredException" is thrown when no user has authenticated, but authentication is required to view the desired resource.

The flaws seem to be at various other locations in the system, where no check is performed to see if a user is authenticated or not before throwing an exception - the exception used would depend on that. I'd like to check with the Flow team what part should be fixed here.


Updated by Adrian Föder over 8 years ago

Will/can this maybe be resolved with https://review.typo3.org/#/c/18695/6 ?


Updated by Andreas Wolf almost 8 years ago

Adrian Föder wrote:

Will/can this maybe be resolved with https://review.typo3.org/#/c/18695/6 ?

No, it is not, at leas not for the case I experienced. I had a new version deployed while being logged in, leading to my session being destroyed. I got an AccessDeniedException, but I would have expected an AuthenticationRequiredException (because no user was authenticated).

I'll dig into this again in the next days.


Updated by Benjamin Heek over 7 years ago

I had the same problem.

I fixed it by setting the `TYPO3.Flow.security.authenticationStrategy` to `allTokens`

Because the AuthenticationProviderManager only throws an `AuthenticationRequiredException` when authenticationStrategy is set to `allTokens`

@see TYPO3\Flow\Security\Authentication\AuthenticationProviderManager->authenticate() line 183:

if ($this->securityContext->getAuthenticationStrategy() === Context::AUTHENTICATE_ALL_TOKENS) {
throw new AuthenticationRequiredException(...);

Also available in: Atom PDF