On 1/2/06, Brian Topping <[EMAIL PROTECTED]> wrote: > After re-reading Elias' first message from 12/31, I realized I might > not have made the changes that I was working on fully clear. I > didn't actually refactor all 40+ calls to pass an autoCreate flag, I > had added a UserManager method with the extra argument, then had the > existing method call through to it with a default argument of > Boolean.FALSE. In this manner, only the specific point of the code > that needed to use the autoCreate would call the new method. > > My sense is that the code would be secure if this single call was > judiciously placed, since none of the existing code would be > affected, but I do have a concern after chatting with Elias that this > call could be misunderstood and improperly used in the future. > > So if what we have below is a pretty good encapsulation of the issues > with auto-create, it seems like we *could* make this work. But > *should* we? > > If we are only doing this for LDAP, and the rolleruser table is not > expected to grow significantly (it seems to be quite small still > after years of development), it might be worth considering the > questions I asked on 12/30. It seems to me that with a few changes > we could make the rolleruser table a runtime optional configuration > and grab the information (in this case) from LDAP. > > Now that Roller is using Acegi, can someone who is an expert with it > answer what kind of abstract facilities it provides for a situation > like this? I presume Acegi will eventually grow to abstract many AAA > strategies, but is it sufficient for current needs and will it grow > with projected needs?
It looks like Acegi's LDAP support will be in the next release (1.0 RC2). http://opensource2.atlassian.com/projects/spring/browse/SEC-12 I don't believe Acegi is the problem in this situation (and in most LDAP + RDBMS situations). It's the relationships between the tables and the user that's an issue. That being said, Acegi is well designed with interfaces and we should be able to hook more deeply into it in the future. In AppFuse, we're reworking the current user-fetching logic to rely on Acegi - at least on the authentication side. I'd love to leverage it for all profile-related activities, but don't know if that'll be possible. http://issues.appfuse.org/browse/APF-118 Matt > > -b > > On Dec 31, 2005, at 4:16 PM, Elias Torres wrote: > > > On 12/31/05, Sean Gilligan <[EMAIL PROTECTED]> wrote: > >> Elias Torres wrote: > >>> > >>> No you are not. I think what Brian is talking about is the fact that > >>> we have to place the code in the right place if not we can open > >>> ourselves to a DOS attack. For example, he was adding > >>> "autoCreate" to > >>> the getUser(username) function in UserData or UserManager. I pointed > >>> out to him that there are many (40+) calls that use this function > >>> like > >>> the RollerAtomHandler class. The handler grabs the userid from the > >>> auth header and calls UserManager.getUser. If we had autoCreate it > >>> would "register" as many users as there are requests to this > >>> servlets. > >>> Hence, a DOS attack. I'm not against autoCreate, all I'm asking is > >>> that we place it in the correct location. > >> > >> I'm not familiar with the code, but it seems to me that the only "use > >> case" where autoCreate needs to be invoked is login (or perhaps an > >> alternatively-configured behavior of register -- i.e. register would > >> create a rolleruser account *only* if the user already exists in the > >> external registry) > >> > >> Rather than change an existing method in UserData or UserManager > >> wouldn't this just be a change in a login or register action? > > > > Correct. My version of the code did it in RollerSession when the > > UserData bean is placed in the session *only* after you've logged in, > > meaning that you are a valid directory user. > > > >> > >> -- Sean > >> > > > > -elias > > > >
