Um, I couldn't disagree more. The current Turbine security model is limited in many aspects. It has only one grouping mechanism - Groups (Or projects). So I can only group my users via the applications they are working on. Or I could group my users by the projects they are working on, but not both. Not to mention, I can't create user groupings - like referring to Jon, Dan, and Jane as the group "Staff Members."
Please refer to my other message and other people's where I explain WHY Turbine's security model doesn't work: http://www.mail-archive.com/turbine-dev%40jakarta.apache.org/msg05102.html - Dan Diephouse Jon Scott Stevens wrote: >$0.00 > >What seems to be missing here and all of the conversations I have seen about >this up until this point, is 'What' we want to secure. > >In other words, we know that we need to have some concept of 'users'...but >once you have that, what are you actually securing? I think that should be >what defines how the security system is built. > >Yes, we realize, we need #1 and #2...but if you think about #2 further, you >need to realize that we need to also answer that question with joins against >other data such as: "is the user part of a project and if so, what roles >does the user have in that project"? > >API's like JAAS are great at securing access to source code. But, they >really don't go beyond that without trying to munge them into something they >aren't. > >Honestly, I don't even see why this conversation is happening. The Turbine >security system is pretty good as it stands. Renaming Group -> Project and >documenting the heck out of it would be the only changes I see as being >necessary in order to have a pretty functional security system for webapps. > >$0.00. > >-jon > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
