Am Montag, 7. August 2017 09:55:45 UTC+2 schrieb Mike Morris:
>
> I have no expertise in the field, but I've chosen not to let that stop me
> from making a suggestion :-)
>
> How about splitting the difference:
>
> 1. Assign & track permissions on the application side, then
> 2. Pass the permission level/parameters into a Stored Procedure in the
> database
>
> If the Stored Procedure accepted permission info, it would not even need
> to know who the user was, just their permissions. (So no need for DB user
> switching, etc) ACLs would be enforced 100% in the DB, while rights
> management stayed in the app.
>
> You'd just have to figure out a flexible enough set or parameters to pass
> into the stored procedure to allow all the permission permutations you
> need... ever... ;-)
>
>
Yes, sounds good. Thank you for your feedback.
> On 08/07/2017 12:42 AM, Andréas Kühne wrote:
>
> Hi,
>
> I understand your concern, however I would like to learn more about how
> you intend to solve the problem. The only way I could see a solution would
> be to change the database user depending on which application user is
> logged in. That would mean updating users and permissions in the database
> every time it changes on the application level. I think this would add a
> lot of complexity that you really don't want.
>
> You could of course have one role for each group you intend to have in the
> application and then apply the permissions accordingly. That would however
> mean that your user permissions solution is very rigid. One of the things
> that I like about django is the ability to add and delete permissions
> easily and swiftly. I'm wondering if you instead couldn't create mixins to
> make sure that the permissions are correct for each object. That way the
> code will be easily testable and also less error prone. However it won't
> create great SQL queries though.
>
> Also - I find that working in Python is a lot easier than working in raw
> SQL :-) but you will of course need to adapt the queries to make them
> faster (which can be done by prefetching for example).
>
> That's just my 2 cents.
>
> Regards,
>
> Andréas
>
> 2017-08-07 8:43 GMT+02:00 guettli <guettli...@thomas-guettler.de
> <javascript:>>:
>
>> Hello this post is now four days old. I would like to hear from other
>> people.
>>
>> Something like:
>>
>> "I have no clue what you are talking about" or
>> "I understand your concerns, but I have no clue, too" or
>> "Thank you about talking about this, this raised my awareness"
>>
>> would make me happy.
>>
>> Thank you.
>>
>> Am Donnerstag, 3. August 2017 10:07:53 UTC+2 schrieb guettli:
>>>
>>> First I asked a similar question on the postgresql-general list. The
>>> discussion[1] has settled there.
>>>
>>> Now I would love the hear what you think.
>>>
>>>
>>> I am thinking about rewriting an existing application which uses PostgreSQL
>>> via Django.
>>>
>>> Up to now the permission checks are done at the application level.
>>>
>>> Up to now queries like: "Show all items which the current user is allowed
>>> to modify" result in complicated SQL and
>>> this leads to slow queries.
>>>
>>> Up to now there is one db-user and the application does the filtering of
>>> rows to prevent application users to see
>>> items which they are not allowed to see.
>>>
>>> I guess most web applications work like this.
>>>
>>> I would like to reduce the "ifing and elsing" in my python code (less
>>> conditions, less bugs, more SQL, more performance)
>>>
>>> One important intention for me: I would like to avoid the redundancy. As
>>> soon as I want to query for
>>> "Show all items which the current user is allowed to modify" I need the
>>> permission checking in a SQL WHERE condition.
>>>
>>> If I implement this. Then my code which might look like this is redundant:
>>>
>>> {{{
>>>
>>> def has_perm(obj, user):
>>> if user.is_superuser:
>>> return True
>>> ...
>>>
>>> }}}
>>>
>>>
>>> Yes, I feel farewell pain. I love Python, but I guess I will use perm
>>> checking via SQL WHERE for new projects in the future.
>>>
>>> What do you think?
>>> Regards,
>>> Thomas Güttler
>>>
>>> [1]:
>>> https://www.postgresql.org/message-id/e662fd8a-6001-514c-71e8-01718444f338%40thomas-guettler.de
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to django-users...@googlegroups.com <javascript:>.
>> To post to this group, send email to django...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/django-users.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-users/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/django-users/b2f0f560-9e83-4a90-9277-23c19f992c0b%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users...@googlegroups.com <javascript:>.
> To post to this group, send email to django...@googlegroups.com
> <javascript:>.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/CAK4qSCfd8Yqo%3DhPKqU_49nhW-6ma-G4QTpo%3DVFzdyRc1F7c7Yw%40mail.gmail.com
>
> <https://groups.google.com/d/msgid/django-users/CAK4qSCfd8Yqo%3DhPKqU_49nhW-6ma-G4QTpo%3DVFzdyRc1F7c7Yw%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/fabcc44d-74d2-4ea9-b83e-56cd888de3e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
