Undefined value using RT::Authen::ExternalAuth::LDAP

RT Users
1

Folks:

Out of the blue I am starting to get this error intermittently. Does
anyone have any idea what it might mean?

Can’t call method “as_string” on an undefined value at
/home/rt/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm
line 304, line 323.

Thanks,

Matt
Matt Adams
Development & Network Services, Cypress Interactive
http://cypressinteractive.com, http://edsuite.com

2

On Mon, 21 Dec 2009 11:43:44 -0700, “Matt Adams”
matt.adams@cypressinteractive.com said:

Out of the blue I am starting to get this error intermittently. Does
anyone have any idea what it might mean?

Can’t call method “as_string” on an undefined value at
/home/rt/local/plugins/RT-Authen-ExternalAuth/lib/RT/Authen/ExternalAuth/LDAP.pm
line 304, line 323.

Check all your ExternalAuth settings in RT_SiteConfig.pm. Things like
‘filter’ and ‘d_filter’ cannot be empty, they must have some value. I
have filter set to ‘(objectClass=*)’ to always match, and d_filter set
to ‘(objectClass=ThisWillNeverMatch)’ to never match (as I have no such
attribute in LDAP).

3

Nick Kartsioukas wrote:

Check all your ExternalAuth settings in RT_SiteConfig.pm. Things like
‘filter’ and ‘d_filter’ cannot be empty, they must have some value. I
have filter set to ‘(objectClass=*)’ to always match, and d_filter set
to ‘(objectClass=ThisWillNeverMatch)’ to never match (as I have no such
attribute in LDAP).

Unfortunately both of those settings are configured properly. This
error just started appearing out of the blue. I haven’t changed
anything recently.

FWIW, I’m using a mod_perl2 configuration.

Matt Adams
Development & Network Services, Cypress Interactive
http://cypressinteractive.com, http://edsuite.com

4

Matt Adams wrote:

Nick Kartsioukas wrote:

Check all your ExternalAuth settings in RT_SiteConfig.pm. Things like
‘filter’ and ‘d_filter’ cannot be empty, they must have some value. I
have filter set to ‘(objectClass=*)’ to always match, and d_filter set
to ‘(objectClass=ThisWillNeverMatch)’ to never match (as I have no such
attribute in LDAP).

Unfortunately both of those settings are configured properly. This
error just started appearing out of the blue. I haven’t changed
anything recently.

It is definitely related to the filter. The problem is in UserExists
which ensures that the user actually exists in the user database, and is
run once for each specified database iirc.

Shortened for simpicity:

my $config = $RT::ExternalSettings->{$service};
my $filter = $config->{‘filter’};

if ($filter eq “()”) { undef($filter) };

if (defined($config->{‘attr_map’}->{‘Name’})) {

Construct the complex filter

$filter = Net::LDAP::Filter->new(
‘(&’ . $filter . ‘(’ . $config->{‘attr_map’}->{‘Name’} . ‘=’ .
$username . ‘))’);
}

my @attrs = values(%{$config->{‘attr_map’}});

Check that the user exists in the LDAP service

$RT::Logger->debug( "LDAP Search === ",
“Base:”,
$base,
“== Filter:”,
$filter->as_string,
“== Attrs:”,
join(‘,’,@attrs));

my $user_found = $ldap->search( base => $base,
filter => $filter,
attrs => @attrs);

The filter information is taken directly from your config and used to
build a filter object. There is then a debug message that uses as_string
to print out the filter object. In your case, $filter is not a defined
object and so the as_string call is invalid.

Double, triple and then quadruple check your filter value in the config.
Kind Regards,

Mike Peachey, IT
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 - Registered In England

5

Mike Peachey wrote:

It is definitely related to the filter. The problem is in UserExists
which ensures that the user actually exists in the user database, and is
run once for each specified database iirc.

Double, triple and then quadruple check your filter value in the config.

I’m not convinced that the filter value is the config is to blame for
this. It hasn’t been changed since the initial installation and
everything has been working up until a little while ago.

I found out what was causing the problem although I still don’t know
why it is a problem.

Someone changed the URL to RT in our wiki to be http://rt?user=john_doe
so that the username would be set automatically as per the wiki
username. Seemed like a smart idea since both authenticate against the
same LDAP server. Whenever this URL is used to get to RT the error appears.

If I remove ?user=john_doe and log in manually everything works just fine.

Does anyone know why this would be? We’re using RT 3.8.5 and
RT::Authen::ExternalAuth 0.08

My problem is solved for the time being but it would be nice to know why
?user=john_doe causes problems.

Thanks,

Matt
Matt Adams
Development & Network Services, Cypress Interactive
http://cypressinteractive.com, http://edsuite.com

6

Hi Matt,

This is nothing more than an uneducated guess, so take it as a grain of
salt, Could it possibly have something to do with writing/maintaining the
cookie/session?

Thanks,
BillOn Mon, Dec 21, 2009 at 12:17 PM, Matt Adams < matt.adams@cypressinteractive.com> wrote:

Mike Peachey wrote:

It is definitely related to the filter. The problem is in UserExists
which ensures that the user actually exists in the user database, and is
run once for each specified database iirc.

Double, triple and then quadruple check your filter value in the config.

I’m not convinced that the filter value is the config is to blame for
this. It hasn’t been changed since the initial installation and
everything has been working up until a little while ago.

I found out what was causing the problem although I still don’t know
why it is a problem.

Someone changed the URL to RT in our wiki to be http://rt?user=john_doe
so that the username would be set automatically as per the wiki
username. Seemed like a smart idea since both authenticate against the
same LDAP server. Whenever this URL is used to get to RT the error
appears.

If I remove ?user=john_doe and log in manually everything works just fine.

Does anyone know why this would be? We’re using RT 3.8.5 and
RT::Authen::ExternalAuth 0.08

My problem is solved for the time being but it would be nice to know why
?user=john_doe causes problems.

Thanks,

Matt

Matt Adams
Development & Network Services, Cypress Interactive
http://cypressinteractive.com, http://edsuite.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

7

That or the fact that that isn¹t valid RFC compliant URI syntax: try
http://rt/?user=john_doe instead. While some web browsers/servers will fake
it and try to work, most standards compliant ones like lighttp and Apache
aren¹t as forgiving.On 12/21/09 12:22 PM, “William Graboyes” william.graboyes@theportalgrp.com wrote:

Hi Matt,

This is nothing more than an uneducated guess, so take it as a grain of salt,
Could it possibly have something to do with writing/maintaining the
cookie/session?

Thanks,
Bill

On Mon, Dec 21, 2009 at 12:17 PM, Matt Adams matt.adams@cypressinteractive.com wrote:

Mike Peachey wrote:

It is definitely related to the filter. The problem is in UserExists
which ensures that the user actually exists in the user database, and is
run once for each specified database iirc.

Double, triple and then quadruple check your filter value in the config.

I’m not convinced that the filter value is the config is to blame for
this. It hasn’t been changed since the initial installation and
everything has been working up until a little while ago.

I found out what was causing the problem although I still don’t know
why it is a problem.

Someone changed the URL to RT in our wiki to be http://rt?user=john_doe
so that the username would be set automatically as per the wiki
username. Seemed like a smart idea since both authenticate against the
same LDAP server. Whenever this URL is used to get to RT the error appears.

If I remove ?user=john_doe and log in manually everything works just fine.

Does anyone know why this would be? We’re using RT 3.8.5 and
RT::Authen::ExternalAuth 0.08

My problem is solved for the time being but it would be nice to know why
?user=john_doe causes problems.

Thanks,

Matt

Matt Adams
Development & Network Services, Cypress Interactive
http://cypressinteractive.com, http://edsuite.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

The rt-users Archives

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Gary L. Greene, Jr.
IT Operations
Minerva Networks, Inc.
Cell: (650) 704-6633
Phone: (408) 240-1239

8

Gary Greene wrote:

That or the fact that that isn�t valid RFC compliant URI syntax: try
http://rt/?user=john_doe instead. While some web browsers/servers will
fake it and try to work, most standards compliant ones like lighttp and
Apache aren�t as forgiving.

I’ve tried both variations and it makes no difference. RT errors out
either way.

Matt Adams
Development & Network Services, Cypress Interactive
http://cypressinteractive.com, http://edsuite.com