I highly recommend that you look at fulcrum secuirty then.. It is designed to have entities that you then mix and match togehter.. so, there is one Model with just users and group. Another one with users and groups and roles and permissions.. This means you define your model, and even easily add your own entities..
Secondly, there is an implementation based on Hibernate, which means you get nice things like lazyloading, caching, and all the other performant aspects of Hibernate. Take a look, if you have a model of your own, I'd love to add it... Eric > -----Original Message----- > From: Brian Lawler [mailto:[EMAIL PROTECTED] > Sent: Friday, April 02, 2004 10:37 PM > To: Turbine Developers List > Subject: Re: null pointer protection in > DefaultTurbineRunData.setUser()... > > > The main problem we have had from the start is that I have a framework > built on top of Turbine that makes different assumptions about the > cardinality of Group, Roles, and Permissions than the out-of-the-box > Turbine solutions have in the past. Specifically, every Member and > Tribe on the tribe.net application has its own Group, resulting in a > group table that currently has upwards of 200,000 entries. Previous > manifestations of turbine security have done really bad things with > that, such as getAllGroups() which for us is a disaster. > > Another issue we ran into was that creating ACLs became heavy, and > caching the ACL in your session meant that if your permissions were > changed by someone else - a site administrator or tribe moderator - you > would not see those changes until the next time you logged in. With > each membership to a tribe being represented as a role in a group the > reloading of all ACL information for each request also became > prohibitive. The solution was to go with a lazy-loading ACL > implementation (which I will be glad to contribute - it's not a very > big deal) > > -B > > > > > On Apr 1, 2004, at 10:11 AM, Eric Pugh wrote: > > > Also, you reimplemented your security? Have you looked at the security > > module in Fulcrum? New and Improved! > > > >> -----Original Message----- > >> From: Brian Lawler [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, April 01, 2004 7:33 PM > >> To: Turbine Developers List > >> Subject: Re: null pointer protection in > >> DefaultTurbineRunData.setUser()... > >> > >> > >> Hm... Perhaps this was a problem that I ran into when I first tried to > >> go to 2.3 but had my security service all messed up - i.e. the > >> setUser(null) may have been an erroneous code path that would not have > >> happened had security been working properly. I will put the app > >> through its paces again without the patch in place and see if it has > >> gone away now that we have re-implemented security. > >> > >> It could also be that with the new Turbine release I am not extending > >> the correct DefaultSessionValidator. I will check into this a little > >> more. > >> > >> -B > >> > >> On Apr 1, 2004, at 3:38 AM, Eric Pugh wrote: > >> > >>> Brian, another quick question, and keep the patches coming.. Why > >>> would > >>> you call setUser(null)? To clear out the user? Should, when you > >>> call > >>> setUser(null) actually replace the user with an AnonymousUser...? > >>> > >>> Otherwise, anywhere where you go data.getUser().somemethod you could > >>> get > >>> null? Take a look at DefaultSessionValidator, it has this chunk of > >>> code: > >>> > >>> // The user may have not logged in, so create a "guest/anonymous" > >>> user. > >>> if (data.getUser() == null) > >>> { > >>> log.debug("Fixing up empty User Object!"); > >>> data.setUser(TurbineSecurity.getAnonymousUser()); > >>> data.save(); > >>> } > >>> > >>> So you will constantly be sticking in a anonymous user.. What is > >>> the > >>> use > >>> case you are trying to accomplish? Maybe we need an explicity > >>> method like > >>> data.clearUser() which would do: > >>> > >>> void clearUser(){ > >>> setUser(TurbineSecurity.getAnonymousUser()); > >>> save(); > >>> } > >>> > >>> Eric > >>> > >>>> -----Original Message----- > >>>> From: Brian Lawler [mailto:[EMAIL PROTECTED] > >>>> Sent: Thursday, April 01, 2004 8:58 AM > >>>> To: Turbine Developers List > >>>> Subject: Re: null pointer protection in > >>>> DefaultTurbineRunData.setUser()... > >>>> > >>>> > >>>> Hmm.. seems like the attachment wasn't allowed through. Here is the > >>>> text of the attachment... > >>>> > >>>> Index: > >>>> src/java/org/apache/turbine/services/rundata/ > >>>> DefaultTurbineRunData.java > >>>> =================================================================== > >>>> RCS file: > >>>> /home/cvspublic/jakarta-turbine-2/src/java/org/apache/turbine/ > >>>> services/ > >>>> rundata/DefaultTurbineRunData.java,v > >>>> retrieving revision 1.16.2.1 > >>>> diff -u -r1.16.2.1 DefaultTurbineRunData.java > >>>> --- > >>>> src/java/org/apache/turbine/services/rundata/ > >>>> DefaultTurbineRunData.java > >>>> 27 Feb 2004 06:08:17 -0000 > >>>> 1.16.2.1 > >>>> +++ > >>>> src/java/org/apache/turbine/services/rundata/ > >>>> DefaultTurbineRunData.java > >>>> 1 Apr 2004 06:35:42 -0000 > >>>> @@ -867,7 +867,7 @@ > >>>> */ > >>>> public void setUser(User user) > >>>> { > >>>> - log.debug("user set: " + user.getName()); > >>>> + log.debug("user set: " + (user == null ? "null" : > >>>> user.getName())); > >>>> this.user = user; > >>>> } > >>>> > >>>> On Mar 31, 2004, at 10:53 PM, Brian Lawler wrote: > >>>> > >>>>> committers- > >>>>> > >>>>> Please find attached a trivial patch that will prevent a null > >>>>> pointer > >>>>> exception being thrown when setUser(null) is called. Is this the > >>>>> correct way to submit these patches? > >>>>> > >>>>> -Brian > >>>>> > >>>>> > >>>>> ------------------------------------------------------------------- > >>>>> -- > >>>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>>> For additional commands, e-mail: > >>>>> [EMAIL PROTECTED] > >>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> - > >>>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [EMAIL PROTECTED] > >>> For additional commands, e-mail: [EMAIL PROTECTED] > >>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
