row level permissions - why?

[Mike]

In my app I need a way to associate objects with a specific user.  Users should not have access to other users objects. I'm implementing this in my model by setting a ForeignKey to the user that owns the object:

owner = models.ForeignKey(User)

Is this a bad idea?  Can someone explain under what circumstances I would need to use a row level permissions app?

[bruno desthuilliers]

On Apr 17, 8:07 am, Mike <mike.t...@gmail.com> wrote:
> In my app I need a way to associate objects with a specific user.  Users
> should not have access to other users objects. I'm implementing this in my
> model by setting a ForeignKey to the user that owns the object:
>
> owner = models.ForeignKey(User)
>
> Is this a bad idea?

Seems quite sensible for the use case you describe.

> Can someone explain under what circumstances I would
> need to use a row level permissions app?

Row level permissions are useful when you have a more complex (and
possibly dynamic) scheme - a common example would be a CMS with public
and restricted areas, per-area admins and a validation/publication
worflow.

[Mike]

One problem I see is that if User 1 somehow obtains a url to a view that displays an object owned by User 2.  User 1 will be able to view User 2's object.  I'll have to write code in every view function that displays user-owned data to make sure that the user actually has permission to view it.

[Tom Evans]

On Tue, Apr 17, 2012 at 12:42 PM, Mike <mike...@gmail.com> wrote:
> One problem I see is that if User 1 somehow obtains a url to a view that
> displays an object owned by User 2.  User 1 will be able to view User 2's
> object.  I'll have to write code in every view function that displays
> user-owned data to make sure that the user actually has permission to view
> it.
>

Or you could decorate your views with an appropriate barrier method.
Something derived from django.contrib.auth.decorators.user_passes_test
would be most appropriate.

Cheers

Tom