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?
-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
