Bug #41029

Method security is also evaluating abstract classes

Added by Rens Admiraal about 9 years ago. Updated over 8 years ago.

Status:
Accepted
Priority:
Should have
Category:
Security
Target version:
-
Start date:
2012-09-18
Due date:
% Done:

0%

Estimated time:
PHP Version:
Has patch:
No
Complexity:

Description

I want to secure all controllers in my vendor namespace except controllers named LoginController, for that I use the following pointcut expression:

ApplicationControllers: 'method(Beech\.*\Controller\.*(?<!Login)Controller->.*Action())'

This did not work at all (webredirect forwards me to the LoginController, and as access is denied on the LoginController chrome stops with a TOO_MANY_REDIRECTS).

Some more debugging learned me that the security framework denied access to the abstract class AbstractController (from which the LoginController extends). Implementing all methods from the abstract class in the LoginController does not solve this. Only extending from a class not matching the pattern (\TYPO3\FLOW3\Mvc\Controller\ActionController) solves the issue and has the expected result.

Imagine the more general pattern: .*\Controller\.*(?<!Login)Controller->.*Action(), this would even match the \TYPO3\FLOW3\Mvc\Controller\ActionController and thus block all access.

Question is: Shouldn't the Security Framework only evaluate the actual classnames being used?

#1

Updated by Karsten Dambekalns almost 9 years ago

  • Project changed from TYPO3 Flow Base Distribution to TYPO3.Flow
#2

Updated by Karsten Dambekalns almost 9 years ago

  • Category set to Security
  • Has patch set to No

So access is denied because your LoginController extends AbstractController and that parent classname is used when matching the expression? Correct?

#3

Updated by Rens Admiraal almost 9 years ago

The parent is also matched... it seems like all classes a class inherits from are also taken into account which would be incorrect.

I would expect it would only affect the class with the exact name matching the pattern, and should not take into account any inheritance whatsoever

#5

Updated by Karsten Dambekalns over 8 years ago

  • Status changed from New to Accepted
  • Assignee set to Karsten Dambekalns

Also available in: Atom PDF