Problems with LDAP Overlay and non-LDAP user creation [WAS: Re: [rt-users] RT could not load a valid user ...]

[Jim Meyer]

Hello!

I think this is related to the LDAP overlay. I may have made a poor
assumption about what CanonicalizeUserInfo should return and why, or it
may be a bug in RT::User::Create(). I need guidance from the RT dev
folks as to what seems most correct. 

If you're desperate to get the LDAP overlay working, there's a quick
hack at the end of this email but you have to promise to take it out
when we have a real solution. I'll make fun of you if you don't. =]

Things seem to break down when autocreating a new user who's not in
LDAP. In this case, RT::User::Create() calls
RT::User::CanonicalizeUserInfo(), the latter being defined in the LDAP
overlay's User_Local.pm. CanonicalizeUserInfo() returns true (1) if the
user is found in LDAP, otherwise it returns false (0). If it returns
false, RT::User::Create() returns failure with the message "Could not
set user info".

As it stands, CanonicalizeUserInfo() must return true (1) at all times
in order to allow non-LDAP users to be created, even if it failed to do
anything; that doesn't seem desirable.

One way to fix this would be to create a config variable to control
whether or not unrecognized users are created (e.g.
$RT::CreateUncanonicalizedUsers); then either RT::User::Create() or
CanonicalizeUserInfo() could heed that variable. Since RT::User::Create
() has this line:

    unless ($self->CanonicalizeUserInfo(\%args)) {

...it gets my vote for change to this:

    unless ($self->CanonicalizeUserInfo(\%args) || 
            $RT::CreateUncanonicalizedUsers) {

We could also do essentially the same thing in CanonicalizeUserInfo()'s
return statement, with this QUICK HACK*:

    return($found || $RT::CreateUncanonicalizedUsers);

That seems less correct as it's no longer a real return value, but
pragmatically speaking, it's very easy to do.

Note that we could hijack $RT::SenderMustExistInExternalDatabase as the
config variable (and negate the logic suggested above), however that
seems tied to the whole WebExternalAuth bit which has always seemed
separate from the LDAP overlay. I'd be worried over adverse side
effects.

O Powers That Be, what say you?

--j

*QUICK HACK made explicit: 

Put this line in your RT_SiteConfig.pm:

   Set($CreateUncanonicalizedUsers, 1);

...and change the return line of CanonicalizeUserInfo() in User_Local.pm
from this:

   return($found);

...to this:

   return($found || $RT::CreateUncanonicalizedUsers);
-- 
Jim Meyer, Geek at Large                                    purp at acm.org