Re: Controlling access at table row level

[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

-- 
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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/8ad1817d-7c6f-435f-8a6f-650a4ed62160%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Controlling access at table row level

[Steve West]

Thanks for the suggestions. I'll give them a try.
Cheers
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+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@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/5f3c185a-0c98-4d90-8520-edfb7ad99e01%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Controlling access at table row level

[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

On 05.11.2015 12:35, Steve West wrote:

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
--
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 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 
.

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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/563B414A.70404%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Controlling access at table row level

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

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 http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/563B3B51.9060302%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.