Controlling access at table row level

[Steve West]

Hi all

I'm implementing a Django project in which individual table rows are marked as either private or public. I need to be able to filter accesses to the tables in such a way that logged-in users can see everything, but other users only get visibility of the 'public' rows. My initial thoughts were that I could apply a check on whether the user is logged in in any of three places: at the model level, in views or in templates. It seemed to me that the most elegant and robust option would be to do so at the model level, by writing custom managers for my models. Within the custom managers, I could check if the user is logged in and filter all queries accordingly.

I did an initial implementation of the above approach, but quickly found problems. Whenever I span foreign key relationships in my views, the default model manager is invoked, so i have had to add in further tests for whether the user is logged in at the view level. I've also got some cases where foreign keys are spanned at the template level and have had to add further login tests there, too.

All-in-all, I don't think I am going about this in the right way!  In the Django documentation, it seems to be mostly expected that one will use authentication to control access to individual views or model operations, rather than controlling finer-grained access to individual rows, so I haven't found anything that really helps.

Can anyone please offer any advice or suggest what would be the best way of solving the problem or point my at any documentation that might help.

Many thanks

Steve

[Mike Dewhirst]

On 5/11/2015 9:35 PM, Steve West wrote:
> Hi all
>
> I'm implementing a Django project in which individual table rows are
> marked as either private or public.

Have you looked at https://github.com/django-guardian/django-guardian

> I need to be able to filter accesses to the tables in such a way that
> logged-in users can see everything, but other users only get
> visibility of the 'public' rows. My initial thoughts were that I could
> apply a check on whether the user is logged in in any of three places:
> at the model level, in views or in templates. It seemed to me that the
> most elegant and robust option would be to do so at the model level,
> by writing custom managers for my models. Within the custom managers,
> I could check if the user is logged in and filter all queries accordingly.
>
> I did an initial implementation of the above approach, but quickly
> found problems. Whenever I span foreign key relationships in my views,
> the default model manager is invoked, so i have had to add in further
> tests for whether the user is logged in at the view level. I've also
> got some cases where foreign keys are spanned at the template level
> and have had to add further login tests there, too.
>

> All-in-all, I don't think I am going about this in the right way! In

> the Django documentation, it seems to be mostly expected that one will
> use authentication to control access to individual views or model
> operations, rather than controlling finer-grained access to individual
> rows, so I haven't found anything that really helps.
>
> Can anyone please offer any advice or suggest what would be the best
> way of solving the problem or point my at any documentation that might
> help.
>
> Many thanks
>
> Steve

> --
> 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
> <mailto:django-users...@googlegroups.com>.
> To post to this group, send email to django...@googlegroups.com
> <mailto:django...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/002471e1-8a64-4637-9d00-ae774924fd84%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/002471e1-8a64-4637-9d00-ae774924fd84%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Jani Tiainen]

Django has foundation for object level (row level) perms:

https://docs.djangoproject.com/en/1.8/topics/auth/customizing/#handling-object-permissions

So basically you just check:

current_user.has_perm('permname', obj)

For a full list of methods you can check:
https://docs.djangoproject.com/en/1.8/ref/contrib/auth/#methods

--
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.
To post to this group, send email to django...@googlegroups.com.

Visit this group at http://groups.google.com/group/django-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/002471e1-8a64-4637-9d00-ae774924fd84%40googlegroups.com.

[Steve West]

Thanks for the suggestions. I'll give them a try.
Cheers
Steve

[Steve West]

I've followed up the suggestions given here but am still struggling with this problem. My table rows are marked as 'public' or 'private' and the suggested approaches (and others I could think of) could certainly control access in such a way that logged-in users could access the whole table and other users coukd only access the 'public' items. So far so good.

The problem that I can't solve is that the same table is accessed by lots of foreign key relationships from other views in various apps. As far as I can tell, the available solutions all either allow the foreign key access to bypass the security or else result in unresolved foreign key accesses that raise exceptions. Either way, I am having to litter my code with either further security checks or checks for foreign keys to non-existent object instances. I'm kind of coming to the conclusion that there is no elegant solution to this but thought I would ask here one more time.

Thanks

Steve