Bug #47995
The method hasRole() in TYPO3/Flow/Security/Account is currently broken
Status: | Closed | Start date: | 2013-05-06 | |
---|---|---|---|---|
Priority: | Should have | Due date: | ||
Assigned To: | Dominique Feyer | % Done: | 0% |
|
Category: | - | |||
Target version: | - | |||
PHP Version: | Complexity: | |||
Has patch: | Yes | Affected Flow version: | Git 2.0 |
Description
Currently this code always return FALSE:
$account->hasRole(new \TYPO3\Flow\Security\Policy\Role('Your.Package:Role')
The hasRole method use the contains method from Doctrine ArrayCollection. Has the two object are different (even is they have the same identifier), the method return FALSE.
I propose to change this method by the same feature found in the SecurityContext hasRole method (who compore the identifer, and the full object).
History
#1 Updated by Gerrit Code Review about 2 years ago
- Status changed from New to Under Review
Patch set 1 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/20555
#2 Updated by Gerrit Code Review about 2 years ago
Patch set 2 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/20555
#3 Updated by Gerrit Code Review about 2 years ago
Patch set 3 for branch master has been pushed to the review server.
It is available at https://review.typo3.org/20555
#4 Updated by Bastian Waidelich about 2 years ago
- Status changed from Under Review to Needs Feedback
The actual "issue" is that roles are entities since #28862
Account::hasRole() won't be the only place where this breaks compatibility.
For instance:
1$account->addRole(new \TYPO3\Flow\Security\Policy\Role('Your.Package:Role');
won't work either - as well as Account::setRoles(), Account::removeRole() and so on.
The way to work around this is not to create new instances but fetch existing roles from the PolicyService:
1$role = $policyService->getRole('Your.Package:Role'); 2$account->hasRole($role);
IMO we need to document this before the release an add visible pointers to the documentation in the release notes
Note: with ValueObjects this might be less breaking but they're currently not properly supported AFAIR
#5 Updated by Christian Müller about 2 years ago
We could try to use VO here. That should solve the mentioned problem. At least for doctrine our implementation should do what is needed.
#6 Updated by Karsten Dambekalns about 2 years ago
One thing we could discuss is what methods should (alternatively) be able to take a string (role identifier). But then again, checking for roles is not really a clever thing in most cases.
Why? Because it ignores the fact that roles might get reconfigured permissions. So if you want to check for access to something, you should rather check if permission to access things is granted, not if a certain role is assigned!
#7 Updated by Bastian Waidelich about 2 years ago
Karsten Dambekalns wrote:
if you want to check for access to something, you should rather check if permission to access things is granted, not if a certain role is assigned!
I agree!
Unfortunately the API for this is not very usable yet (at least some convenience method would do good). Currently I have to add this snippet in my base controllers:
1/** 2 * Check if we currently have access to the given resource 3 * 4 * @param string $resource The resource to check 5 * @return boolean TRUE if we currently have access to the given resource 6 */ 7protected function hasAccessToResource($resource) { 8 try { 9 $this->accessDecisionManager->decideOnResource($resource); 10 } catch (AccessDeniedException $e) { 11 return FALSE; 12 } 13 return TRUE; 14}
#8 Updated by Karsten Dambekalns about 2 years ago
Bastian Waidelich wrote:
Unfortunately the API for this is not very usable yet (at least some convenience method would do good). Currently I have to add this snippet in my base controllers:
[...]
Full Ack. What about adding that to some clever place?
#9 Updated by Dominique Feyer about 2 years ago
Thanks for all those information, I update my application based on it, and everything work fine.
I need to spend more time on the decisionMaker, but currently my role configuration are really simple so I can rely on simple hasRole logic.
All the information in this issue will have a better visibility in the official documentation I think. The change around Role can be frustrating without that.
#10 Updated by Bastian Waidelich about 2 years ago
- Status changed from Needs Feedback to Closed
Thanks for the feedback Dominique,
We'll definitely have to add a comprehensive "breaking changes" section to documentation & release notes with code examples and such.