Skip to content
  • Benjamin Franzke's avatar
    [TASK] Propagate "immediate" responses through the middleware stack · f179a57f
    Benjamin Franzke authored and Benni Mack's avatar Benni Mack committed
    When a controller finds some pre-requisites of the called
    action are not fulfilled, it can create an 'early' response
    and throw it as ImmediateResponseException. This exception
    bypasses the middleware stack, and is caught in the Application
    to emit the response. This is a big win in contrast to
    die/exit calls.
    
    Some middlewares however expect to be always called when the
    response bubbles up. Good examples are 'locking' middlewares:
    They set up a lock when called, dispatch to inner middlewares,
    and tear town the lock when a response is retrieved.
    
    The tear down code of those middlewares is bypassed when
    a controller throws an ImmediateResponseException.
    
    The patch introduces a second exception: PropagateResponseException.
    This one is caught by a new very inner middleware positioned at the
    end of the middleware stack, just before the request is dispatched
    to some controller. It then sends the response up the outer
    middlewares. This allows middlewares like a 'locking' middleware
    to do it's job without being bypassed, and at the same time
    allows a controller to bypass any further local processing by
    throwing such a response exception.
    
    ImmediateResponseException exists as before and can still be used
    to directly bypass the middleware stack and is kept as safety net
    in case a PropagateResponseException is thrown within a middleware.
    PropagateResponseException therefore extends ImmediateResponseException.
    
    It's however discouraged to throw ImmediateResponseException from
    within controllers - they require knowledge on what middlewares
    do in their 'tear down' part and there shouldn't be a reason to
    bypass them.
    
    Middleware/BackendUserAuthenticator is adapted to properly
    handle ImmediateResponseException that would have been thrown
    BackendUserAuthentication::backendCheckLogin(). BackendUserAuthentication
    is therefore refactored to allow to call the backend login
    initialization without (duplicate) login check.
    This allows to propagate redirect/maintenance responses.
    
    Releases: master
    Resolves: #93007
    Change-Id: I291d9d532e7fa289b803e5eef38b23402e57e8ba
    Reviewed-on: https://review.typo3.org/c/Packages/TYPO3.CMS/+/67042
    
    
    Tested-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
    Tested-by: default avatarTYPO3com <noreply@typo3.com>
    Tested-by: default avatarBenni Mack <benni@typo3.org>
    Reviewed-by: default avatarChristian Kuhn <lolli@schwarzbu.ch>
    Reviewed-by: default avatarBenni Mack <benni@typo3.org>
    f179a57f