I may be reading this wrong, but couldn't you just define your custom
attributes in `__customer_acl__` and `__api_acl__`, then define `__acl__`
as a custom property on a shared base class that simply proxies the
attributes in the lookup order you want over to Pyramid's default policy?
--
You r
I would not expect to fallback if you specify an attribute different than
__acl__ and have not implemented it. From a security perspective I would
find that risky to get unintended behaviour due to accidents.
My model classes have attributes like this:
def __customer_acl__ ...
def __api_acl__ ...
It seems to me that allowing this to be modified is fairly harmless.
Would you expect it to fallback to __acl__ if it doesn't find the
custom method/attribute? Or would you expect it to be changed
wholesale? The issue in changing it wholesale and still calling it the
ACLAuthorizationPolicy is that
This sounds like it would actually be helpful for me too for the project
we're about to embark on, if I'm understanding the OP correctly.
my two cents Canadian!
iain
On Thu, Jun 11, 2015 at 10:04 AM, Chris McDonough wrote:
> Id like to hear other people speak up who have needed the same knob. I
Id like to hear other people speak up who have needed the same knob. If this
is something a few people have needed, I'd ask them if their life would be much
better with a knob on aclauthorizationpolicy instead of a custom policy given
that they would also need to document it and justify it in
Hi,
I am implementing an application that is structured in way where I have a
business model and multiple Pyramid applications on top of that, ending up
with 4 processes, two of them providing APIs (XML-RPC) and two of them
providing UIs.
I'm happy using the ACLAuthenticationPolicy but I notic
