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]



Reply via email to