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.
-- Allen
Thanks!
- Dave
