On Monday, September 22, 2014 5:00:26 PM UTC-4, Brian the Lion wrote:
>
>
> In my scheme, I think there's a role both for silent omission and 
> error-throwing. For example, getting a list of all managed objects' primary 
> keys should silently omit objects that the caller doesn't have permission 
> to view. Direct access to object attributes, however, should throw an error.
>
> If I really wanted just individual entities to say, "you're not allowed to 
>> read or change me!" upon access, but I don't need "real" security, I'd 
>> probably implement that as a __getattribute__()/__setattr__() type of 
>> thing. 
>>
> Following @Matthias' intuition about the PreFilteredQuery, I hypothesize 
> that I can keep much of the code at the SQLA level rather than pushing it 
> up to the application level. Here's what I was thinking:
>
>    - Each permissions-managed class will be foreign-keyed to a 
>    Permissions object.
>    - I will provide a new Session class, the AuthSession class. This 
>    class will take a (username, password) argument at __init__. From there 
> on, 
>    it will act just like a standard Session except that it will pre-filter 
> all 
>    queries, updates, deletes, and inserts by checking the permission model 
>    first. 
>
>
I had a similar need in the past.  I ultimately decided that this was best 
left outside of sqlalchemy. 

Trying to do it in SqlAlchemy had 2 large issues:

• everything seemed needlessly complex (trying to adapt sqlalchemy into 
this much higher level concept)
• i was enforcing "application user" constraints onto the "developer user"

my workaround was to use a proxy wrapper for reads, and an internal api for 
writes.

• lightweight wrapper couples a "permissions" object with sqlalchemy 
results.  permissions object is consulted for ACL on properties, and just 
proxies requests to the underlying object.  the app code wraps everything 
in that object.
• no application code "writes" on the objects, only some library routines 
that consult the wrapper objects ACLs and perform operations on the 
underlying object

it wasn't as elegant as a super sqlalchemy object approach, but it was 
quick to cobble together and hit all my business goals.

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.

Reply via email to