(Third Attempt To Post)Complex Application Security Model

[lin...@gmail.com]

Note: I have tried to post this two other time, but the thread wasn't
added to the group. I apologize if this shows up multiple times on the
list. I just want to make sure that it's being sent out.
-------------------------------------------------------------------------------------------------------------------------------------------------

All,
I'm trying to add some security features in my application that would
provide the following functionality:

1)Isolate each instance of an object from other users. For example, if
users A, B, & C create schedules, they should only be able to act on
there own schedules by default.
2)Grant Specific rights on objects, "schedules" , that the user
owns. Here are some scenarios:
- Lest say that user A would like to give user B the ability to view
their schedule, but nothing else.
- User A would like to give user C the ability to view and edit their
schedule.
- User B would like to give everyone the ability to view there
schedules(make it public).
3) The ability to create and use new permissions.

As you can see, I'm just trying to give each user the ability to
control what is done with there objects. I have been playing around
with different methods of achieving this with Django, but haven't be
able to resolve the issue yet. Here is a prototype (see model below)
where I create a custom group with members and permissions. This would
allow the user to create a group that they own named "Schedule
Viewers" and add users to the group members list, then give them the
view permission. This also gives the user the ability to easily
associate a group for each schedule object. The idea is to filter
queries by owners, and group members with there permissions. I
initially tried using the built in group and group permissions tables,
but couldn't determine how to isolate the groups and permissions from
other users.

This all leads me to a number of questions:
- Is this prototype way off base(see model below), if not how could I
improve or fix this design?
- Is there a way to solve this problem with the built in authentication
tools?
- If there isn't do you know of another method of solving this problem?

I'm working on a fairly tight deadline, so I may not have time to roll
my own, especially with my current intermediate Django skill level. I
have looked at the RLP branch, but do not want to build against
something that isn't in the development trunk or a well maintained
Plugin.

Here is the current iteration of the prototype model:
===============================================================
from django.db import models
from django.contrib.auth.models import User

# Create your models here.

class AccountGroup(models.Model):
owner = models.ForeignKey(User, related_name='owners')
name = models.CharField(maxlength=50)
grant_view = models.BooleanField(default=False, blank=True,
null=True, help_text="Optional")
grant_edit = models.BooleanField(default=False, blank=True,
null=True, help_text="Optional")
grant_delete = models.BooleanField(default=False, blank=True,
null=True, help_text="Optional")
grant_create = models.BooleanField(default=False, blank=True,
null=True, help_text="Optional")
grant_all = models.BooleanField(default=False, blank=True,
null=True, help_text="Optional")
members = models.ManyToManyField(User,related_name='members')

def __str__(self):
return "%s, %s" %(self.name, self.members.all())

class Admin:
# Currently only returns the object references for members.
list_display = ('name', 'members',)

class Schedule(models.Model):
owner = models.ForeignKey(User)
acct_grp = models.ForeignKey(AccountGroup, blank=True, null=True,
help_text="Optional")
public = models.BooleanField(default=False, null=True,
help_text="Optional")
start_date = models.DateField(blank=True, null=True,
help_text="Optional")
start_time = models.TimeField(blank=True, null=True,
help_text="Optional")
end_date = models.DateField(blank=True, null=True,
help_text="Optional")
end_time = models.TimeField(blank=True, null=True,
help_text="Optional")

def __str__(self):
return "%s, %s, %s, %s " %(self.start_date, self.start_time,
self.end_date, self.end_time)

class Admin:

list_display = ('start_date','start_time','end_date',
'end_time',)

class Meta:
#Add some addtional permissions to test/play with this
fuctionality.
permissions = (
("can_view", "Can View"),
("can_edit", "Can Edit"),
("can_confirm", "Can Confirm"),

)

=========================================================================
Your advice is much appreciated!

Regards,
Nick Pavlica

[Ian Holsman]

Hi Nick.

can you tell me how this is different that the stuff Chris Long
worked on in his branch?
It seems very similar.

regards
Ian.

--
Ian Holsman
I...@Holsman.net
http://VC-chat.com It's what the VC's talk about

[lin...@gmail.com]

Hi Ian,
This is very similar to what Chris has done. The issue is that his
code hasn't been merged with Trunk, which puts me in an awkward
position in terms of adopting it for something that is outside the
scope of a test application. I started working on a solution to this
problem a few months ago, then saw the initialization of the RLP
project around 5/27/06. I stopped working on that problem and started
working on the application, figuring out the model design, etc. Nearly
five months have passed and I'm at a point where I need to solve this
problem in a logical and sustainable fashion. I would much rather use
the RLP and GA tools, but little progress has been made on there
adoption. I realize that the contributing members of the project are
busy, but I'm running out of time, and need to meet a deadline. I
would even be willing to cough up a few hundred dollars for someone to
help as long as I can meet the requirements of my application, and the
code was adopted in Trunk. I have about two weeks, to come up with a
solution to this issue. I have thought about moving this project to
TurboGears or Rails(+Plugins) because they have libraries that address
this type of problem. I would appreciate any suggestions.

-- Nick

[Ian Holsman]

On 20/10/2006, at 9:01 AM, lin...@gmail.com wrote:

>
> Hi Ian,
> This is very similar to what Chris has done. The issue is that his
> code hasn't been merged with Trunk, which puts me in an awkward
> position in terms of adopting it for something that is outside the
> scope of a test application.

here is what I hear you saying.

you'd rather write your own code to do the same/similar thing to what
chris
has already done (and also what has a high chance of getting merged
in the
coming months).

and as it's your own code, you are also willing to handle all the
merges, bugfixes,
and potential incompatiblies in it by yourself, and on your own dime.

If you have an active interest in Chris's code, may I suggest you
petition the powers
that be for a SVN account on it, and modify it instead of writing it
the same functionality yourself.

that way you can keep it current with the trunk (just like you would
have to do with your own)
and get it to a state where the trunk maintainers will feel much more
confident with merging it back
into the trunk.

That is how I would justify working on it to my boss at least ;-)

regards
Ian

> I started working on a solution to this
> problem a few months ago, then saw the initialization of the RLP
> project around 5/27/06. I stopped working on that problem and
> started
> working on the application, figuring out the model design, etc.
> Nearly
> five months have passed and I'm at a point where I need to solve this
> problem in a logical and sustainable fashion. I would much rather use
> the RLP and GA tools, but little progress has been made on there
> adoption. I realize that the contributing members of the project are
> busy, but I'm running out of time, and need to meet a deadline. I
> would even be willing to cough up a few hundred dollars for someone to
> help as long as I can meet the requirements of my application, and the
> code was adopted in Trunk. I have about two weeks, to come up with a
> solution to this issue. I have thought about moving this project to
> TurboGears or Rails(+Plugins) because they have libraries that address
> this type of problem. I would appreciate any suggestions.
>
> -- Nick
>
>
> >

--
Ian Holsman
I...@Holsman.net
http://car-chatter.com/ where car fanatics meet

[Noah]

This sort of thing is asked for time and time again, is there any idea
when Chris' code will be ready?

[Malcolm Tredinnick]

On Thu, 2006-10-19 at 16:40 -0700, Noah wrote:
> This sort of thing is asked for time and time again, is there any idea
> when Chris' code will be ready?

It's already "ready" and able to be used. Chris keeps his branch in sync
with trunk regularly and is extremely responsive to fixing bugs. It will
be merged when we have had a chance to review it thoroughly. Don't be
afraid of using an active branch. That's why they exist -- so that
people can use them and test them out.

Regards,
Malcolm

[lin...@gmail.com]

> here is what I hear you saying.
>
> you'd rather write your own code to do the same/similar thing to what
> chris
> has already done (and also what has a high chance of getting merged
> in the
> coming months).

What I'm trying to say, is that I was working to implement something
that wouldn't impact the current functionality of Django so that I
could run off of trunk without continually patching it, etc. However,
after diving in, it became clear that this is a fairly complex problem
that would warrant the level of work that Chis/Joseph/Others have put
into solving this problem. I was hoping that someone would have a
trick up there sleeve.

>
> and as it's your own code, you are also willing to handle all the
> merges, bugfixes,
> and potential incompatiblies in it by yourself, and on your own dime.
>

Actually, I would like to avoid this, and is why I offered to come up
with some money out of my own pocket so that everyone in the community
could benefit from this feature.

> If you have an active interest in Chris's code, may I suggest you
> petition the powers
> that be for a SVN account on it, and modify it instead of writing it
> the same functionality yourself.

This is definitely worth considering.

>
> that way you can keep it current with the trunk (just like you would
> have to do with your own)
> and get it to a state where the trunk maintainers will feel much more
> confident with merging it back
> into the trunk.
>

Actually, I'm not sure why this isn't already in trunk. To my
knowledge it doesn't dramatically affect the current auth system, it
just extends it (I would like to have Chris's verify that of course).
Jay Parlor and others have mentioned that they were looking at the RLP
branch and have reported some of the early bugs, of which Chris
promptly fixed. I played around with the branch and things generally
seemed to work as prescribed. Is it possible that the core maintainers
are to busy to worry about functionality that they don't really need .
I have noticed that some features have been adopted to trunk rather
quickly without nearly as much testing as the RLP code has already had.

> That is how I would justify working on it to my boss at least ;-)

I'm my own boss, that is why I have to get things done. When I worked
in the Corporate world I could just say "The project will be delayed,
and by the way has accounting issued our paychecks " :)

Thanks for your helpful advice!
--Nick

[lin...@gmail.com]

Malcolm ,
Thanks for you for your contributions, your presence on this project
really makes a positive difference.

> It's already "ready" and able to be used. Chris keeps his branch in sync
> with trunk regularly and is extremely responsive to fixing bugs. It will
> be merged when we have had a chance to review it thoroughly.

Here is a small offer that I would like you to consider:
I would be willing to pay you a couple hundred dollars $US to get this
done by next Friday(10/27/06). I wish it could be more, I'm just on a
very tight budget.

Regards
--Nick

[Malcolm Tredinnick]

Hi Nick,

Whilst the idea isn't a bad one, I don't think I can accept this for a
few reasons. Firstly, I don't think I have time in the next seven days
to give it the concentration it deserves, since I already have
commitments to paying clients and a couple of other things due.
Secondly, I don't get ultimate say in these things -- apparently my
ideas are listened to by Adrian and Jacob, but they still get final say
and they are as busy as I am, by the looks of things. So any guarantees
I could make would not be sufficient.

Finally, I don't think it would be right for me to accept money for this
type of job, getting something into the repository. If somebody wanted
to pay me to do a particular piece of development on Django core and the
price was right, I would certainly accept it (I've taken professional
Django jobs previously and working on the main code or a project is all
pretty much the same). However, that would not come with a cast-iron
guarantee it would make it into core; just that it would go through the
normal channels (the usual way commerical contributions to Open Source
projects work). It's this last step -- actually getting the code into
core, if it's a big change -- that cannot be for hire. I don't have the
authority and I also don't believe it contributes positively to a
project (this is the same principle that the Linux kernel, GNOME, KDE
and many other projects all operate under for the same reason).

To help you out, I can only repeat what I said before: all the
indications are that this branch is of a high quality and Chris is
working actively on fixing any problems as they arise. So if I was
personally in a position where I really need row-level permissions, I
would develop code against that branch on the grounds that it is
reasonably up-to-date and likely to be merged back to the trunk in the
near future. It makes sense to me from a technical risk perspective. If,
however, you only want to work against the trunk, then you have the
alternative you mentioned in your initial post: manage the permissions
yourself outside of the core. A little more work, but not impossible to
pull together an application-specific solution, I'm sure.

Best wishes,
Malcolm

[Jay Parlar]

Since I saw my name (incorrectly spelled) show up in this thread, I'll
throw my 2 cents in (That's CDN, now almost worth 2 cents US!)

I'm using Chris Long's branch on a production site right now. It's
nothing major, a volunteer organization with minimal needs, but for my
limited uses, it is working. I have to warn though, ALL of my uses for
it are at the Admin level. The *entire* site is generic views. I only
use the RLP branch to make sure that people with Admin accounts can't
edit other peoples' articles, unless I've given them permission to do
so. And for that, it's working great.

As has been stated in this thread a few times, Chris Long has been
quite good about bug fixes. Not only that, he's been really good about
merging trunk changes into the branch.

That said, it'd be nice to see the branch actually put into the trunk,
but that won't happen without more people playing around with it. And
like me, I know a lot of people are short on time these days. I would
worry that Chris might lose interest if there's no movement (as anyone
in his position might do.

Jay P.

[Ramdas S]

How do I integrate the per-object-permissions trunk to my regular django trunk which powers the web site.

I checked the per-object-permissions trunk it works properly at least as far as my simple cms apps are concerned.

Ramdas

[Jay Parlar]

On 10/20/06, Ramdas S <ram...@gmail.com> wrote:
> How do I integrate the per-object-permissions trunk to my regular django
> trunk which powers the web site.
>
> I checked the per-object-permissions trunk it works properly at least as far
> as my simple cms apps are concerned.
>

You'll have to do an 'svn switch' to the branch, then a 'manage.py
syncdb' to add the new tables that POP requires.

Jay P.