On Jun 3, 2008, at 2:41 PM, Allen Gilliland wrote:
Dave wrote:
On Mon, May 26, 2008 at 3:19 PM, Allen Gilliland
<[EMAIL PROTECTED]> wrote:
For completeness' sake I've spent a few hours messing around with
my ideas
and prototyping to see if they make sense. Here's the results ...
http://cwiki.apache.org/confluence/display/ROLLER/More+Abstract+Security+Model
I've also created a patch against the current trunk with actually
applies
these things and the changes are all additions to the code for the
most
part, so they work side-by-side with the existing implementation
if you want
to apply the patch and compare.
I took a look at this patch today and I think it looks good. Overall
it's cleaner and easier to understand. Also, looks like the UI /
Struts 2 changes will be pretty small to cut over to the new
objects/methods you have proposed. So I'm +1 on the patch and willing
ot help with those Struts 2 changes.
Cool. Anyone else who is interested in the security model want to
weigh in?
One of the things the patch didn't include was the mappings of
implied permissions. We could use a little more thought in that
area. We need both a way of persisting the implied permission
relationships as well as a way to query for them. I had thought
this might also be something that would be done through the
UserManager since it's tied to permissions, but don't have strong
feelings about it.
I am hoping that we can actually persist the implied permission
mappings in the db and make them dynamic, thus allowing us to add/
modify/remove permissions at runtime. This isn't a requirement
right now though, so just putting them in the static config is fine
for now.
The other thing I am interested in now is David Jencks idea of
having a separate UserSource interface. Originally this seemed
excessive to me, but after doing the comment authentication work I
realize that this could be very useful if not necessary. The main
need for this comes from the need to be able to get the information
about a User from more than just a single data store. i.e. in
comment authentication we want commenters to authenticate against a
3rd party system, not the local db, which creates the problem of
"where do I get the User object from if UserManager.getUser() only
looks against the local db?"
That is also just more food for thought and is not a true necessity
right now, but I am thinking it makes a lot of sense.
I'm going to try and work on this a bit more this weekend.
I'll try to make some time to look at the comments and your proposal
soon... I've been very busy lately, haven't lost interest :-)
thanks
david jencks
-- Allen
Thanks!
- Dave
