You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The expected outcome would be false but it returns true because in Acl::getRuleType() null is returned when the assertion is returning anything else than true.
A simple fix would be returning the assertion value if it is not null but I think I am missing some point here or this is something that is simply overlooked in the design.
If I did miss something please advice how to implement my assertions because I have assertions that are dedicated to a specific resourceId + roleId + privilege combination and I don't want to assign this whole combination to the assertion and let it check if this assertion is really meant for that call..
For example, staff can manage acl roles for users except for 2 users. This is not possible now since the inherited value which allows this behavior when it is actually denied.
Just to be clear, if an assertion exists and is returning otherwise than null stop searching and return that value instead of the parent resource's value.
Adds an assertion class to the test suite, and a unit test that
exercises it to demonstrate the scenario presented in laminas#2.
Signed-off-by: Matthew Weier O'Phinney <[email protected]>
weierophinney
added a commit
to weierophinney/laminas-permissions-acl
that referenced
this issue
Sep 21, 2020
If the provided assertion has run, it, and it alone, should be used to determine the rule type returned.
When a `true` value is returned, the rule type is returned as defined.
When a `false` value is returned, the rule type returned is the inverse of the one defined.
Fixeslaminas#2
Signed-off-by: Matthew Weier O'Phinney <[email protected]>
Adds an assertion class to the test suite, and a unit test that
exercises it to demonstrate the scenario presented in #2.
Signed-off-by: Matthew Weier O'Phinney <[email protected]>
If the provided assertion has run, it, and it alone, should be used to determine the rule type returned.
When a `true` value is returned, the rule type is returned as defined.
When a `false` value is returned, the rule type returned is the inverse of the one defined.
Fixes#2
Signed-off-by: Matthew Weier O'Phinney <[email protected]>
This issue has been moved from the
zendframework
repository as part of the bug migration program as outlined here - http://framework.zend.com/blog/2016-04-11-issue-closures.htmlOriginal Issue: https://api.github.com/repos/zendframework/zendframework/issues/7385
User: @BWorld
Created On: 2015-03-30T20:37:41Z
Updated At: 2015-11-06T21:03:17Z
Body
Hi,
I have the following setup:
http://pastebin.com/ZGsH8M1F
The expected outcome would be false but it returns true because in Acl::getRuleType() null is returned when the assertion is returning anything else than true.
A simple fix would be returning the assertion value if it is not null but I think I am missing some point here or this is something that is simply overlooked in the design.
If I did miss something please advice how to implement my assertions because I have assertions that are dedicated to a specific resourceId + roleId + privilege combination and I don't want to assign this whole combination to the assertion and let it check if this assertion is really meant for that call..
For example, staff can manage acl roles for users except for 2 users. This is not possible now since the inherited value which allows this behavior when it is actually denied.
Just to be clear, if an assertion exists and is returning otherwise than null stop searching and return that value instead of the parent resource's value.
Thanks
Originally posted by @GeeH at zendframework/zend-permissions-acl#20
The text was updated successfully, but these errors were encountered: