I’m working integrating RT into our LDAP infrastructure, and ran into
a question. The function RT::EmailParser::LookupExternalUserInfo()
seem to be intended for one of the features we need. I want to map
mail address to local username when a new user is to be created when a
new mail is recieved. But this function do not seem to be used.
Which part of the code is supposed to call this function? I suspect
Email/Auth/MailFrom.pm is the best place to insert the call. Is this
patch on the right track?
— lib/RT/Interface/Email/Auth/MailFrom.pm 2004-03-28 06:04:08.000000000 +0200
+++ local/lib/RT/Interface/Email/Auth/MailFromPere.pm 2004-08-25 18:29:03.000000000 +0200
@@ -36,11 +36,27 @@
@_ );
-
We don’t need to do any external lookups
- my $Username = undef;
my ( $Address, $Name ) = ParseSenderAddressFromHead( $args{‘Message’}->head );
- my ($UserFoundInExternalDatabase, %ExternalUserInfo) =
-
RT::EmailParser::LookupExternalUserInfo( undef, $Address, $Name );
- if ($UserFoundInExternalDatabase) {
-
$Username = $ExternalUserInfo{'Name'} if $ExternalUserInfo{'Name'};
-
$Address = $ExternalUserInfo{'EmailAddress'}
-
if ($ExternalUserInfo{'EmailAddress'});
-
$RealName = $ExternalUserInfo{'RealName'}
-
if ($ExternalUserInfo{'RealName'});
- }
my $CurrentUser = RT::CurrentUser->new();
- $CurrentUser->LoadByEmail($Address);
-
Try username first
-
$CurrentUser->LoadByName($Username) if $Username;
-
unless ( $CurrentUser->Id ) {
-
$CurrentUser->LoadByEmail($Address);
-
}
unless ( $CurrentUser->Id ) {
$CurrentUser->LoadByName($Address);
}
@@ -117,7 +133,7 @@
}
- $CurrentUser = CreateUser( undef, $Address, $Name, $Address, $args{‘Message’} );
-
$CurrentUser = CreateUser( $Username, $Address, $Name, $Address, $args{‘Message’} );
return ( $CurrentUser, 1 );
}
With this modification, I’m able to use a replacement
RT::EmailParser::LookupExternalUserInfo() function (in my local
EmailParser_Local.pm) to look up the username in LDAP and get RT to
behave as I want. If this change is correct, please include it in the
next version of RT.
[Petter Reinholdtsen]
Which part of the code is supposed to call this function? I suspect
Email/Auth/MailFrom.pm is the best place to insert the call. Is this
patch on the right track?
Digging deeper, I found User::CanonicalizeUserInfo() which could use a
call to RT::EmailParser::LookupExternalUserInfo() as well, to make
sure new users are created with the information updated from the
external source.
Here is my proposed patch.
— lib/RT/User_Overlay.pm.orig 2004-07-12 20:00:53.000000000 +0200
+++ lib/RT/User_Overlay.pm 2004-08-26 12:14:27.000000000 +0200
@@ -670,6 +670,15 @@
my $args = shift;
my $success = 1;
- my %ExternalUserInfo =
- my ($UserFoundInExternalDatabase, %ExternalUserInfo) =
-
RT::EmailParser::LookupExternalUserInfo( undef, $Address, $Name );
- if ($UserFoundInExternalDatabase) {
-
for my $key (keys %ExternalUserInfo) {
-
$userhashref->{$key} = $ExternalUserInfo{$key};
-
}
- }
return ($success);
}
Is this correct? If it is, please include in a future version of RT.
Petter Reinholdtsen wrote:
[Petter Reinholdtsen]
Which part of the code is supposed to call this function? I suspect
Email/Auth/MailFrom.pm is the best place to insert the call. Is this
patch on the right track?
Digging deeper, I found User::CanonicalizeUserInfo() which could use a
call to RT::EmailParser::LookupExternalUserInfo() as well, to make
sure new users are created with the information updated from the
external source.
Here is my proposed patch.
— lib/RT/User_Overlay.pm.orig 2004-07-12 20:00:53.000000000 +0200
+++ lib/RT/User_Overlay.pm 2004-08-26 12:14:27.000000000 +0200
@@ -670,6 +670,15 @@
my $args = shift;
my $success = 1;
I think that RT::User object shouldn’t call any sub from EmailParser
namespace. LookupExternalUserInfo should be moved from mail parser code
may be into User class or into new package that would contain helper
functions for external users database handling.
Another reason why LookupExternalUserInfo should be moved from mail
parser is that this function is general for all interfaces, web, mail or
other doesn’t matter.
Best regards. Ruslan.
[Ruslan U. Zakirov]
I think that RT::User object shouldn’t call any sub from EmailParser
namespace. LookupExternalUserInfo should be moved from mail parser
code may be into User class or into new package that would contain
helper functions for external users database handling.
Another reason why LookupExternalUserInfo should be moved from mail
parser is that this function is general for all interfaces, web, mail or
other doesn’t matter.
I agree that it is probably misplaced in EmailParser. It would also
be usefull if the function wasn’t a member function ($self is unused,
and not really usefull).
I suspect the RT::User class is the best place for this. With the
proper hooks in MailFrom.pm and User_Overlay.pm, I would get LDAP
authentication and information transwer by only making a
User_Local.pm. That would be good. 
(Even better would be to get the LDAP support integrated into the
official RT distribution. Would it be possible for the RT maintainers
to let me know what would be needed for this to happen?
Petter Reinholdtsen wrote:
[Ruslan U. Zakirov]
I think that RT::User object shouldn’t call any sub from EmailParser
namespace. LookupExternalUserInfo should be moved from mail parser
code may be into User class or into new package that would contain
helper functions for external users database handling.
Another reason why LookupExternalUserInfo should be moved from mail
parser is that this function is general for all interfaces, web, mail or
other doesn’t matter.
I agree that it is probably misplaced in EmailParser. It would also
be usefull if the function wasn’t a member function ($self is unused,
and not really usefull).
I suspect the RT::User class is the best place for this. With the
proper hooks in MailFrom.pm and User_Overlay.pm, I would get LDAP
authentication and information transwer by only making a
User_Local.pm. That would be good.
Better.
(Even better would be to get the LDAP support integrated into the
official RT distribution. Would it be possible for the RT maintainers
to let me know what would be needed for this to happen?
RT can’t handle everything and LDAP is not only interface for external
user lookups. The best solution is front-end interface in RT that would
handle interaction with external source of info about users. If you want
enable LDAP then you write module(or use one from CPAN,
RTx::Authen::LDAP) that inherit this interface and provide required
functionality, then you put into RT_SiteConfig.pm Set($AuthenClass,
“RTx::Authen::LDAP”); and Set($AuthenOptions, {…some options that
module could require…});
IMHO RT itself can use this interface for authentication against
internal database.
All this is just words unless someone try to implement it. We don’t use
external users DB, yet. So I didn’t investigate problem deeply.
Best regards. Ruslan.