AFAIR if you return from a hook like that, it is supposed to
terminate the hook chain and proceed.
So in this case, as long as the password matches when StaticPassword
returns, then you are good to go.
Solution would be not to use StaticPassword
Artur
On Aug 6, 2008, at 10:26 AM, Jos I. Boumans wrote:
Greetings,
I was just changing a simple app to move away
from ::Authen::AllowedUsers to
something that authenticates against one of our local systems, when
i noticed
I could connect using *any* username, no matter how i
configured ::Authen::AllowedUsers.
A bit of debugging shows that the callbacks in there never get
called. This
looks to be due to me also using ::Authen::StaticPassword (same as
the test
framework), which has a callback that does this:
sub get_password {
my ($self, $cb, %args) = @_;
$cb->set($self->{password});
}
Since the GetPassword callback is run before the CheckCleartext
one, this
->set() is called before AllowedUsers (or any other user/password
check for
that matter), which calls the following code in IQ.pm:
if ($can_get_password) {
$vhost->run_hook_chain(phase => "GetPassword",
args => [ username => $username, conn => $conn ],
methods => {
set => sub {
my (undef, $good_password) = @_;
if ($password && $password eq
$good_password) {
$accept->();
} elsif ($digest) {
my $good_dig = lc(Digest::SHA1::sha1_hex
($conn->{stream_id} . $good_password));
if ($good_dig eq $digest) {
$accept->();
} else {
$reject->();
}
} else {
$reject->();
}
},
},
fallback => $reject
This means that any plugin that returns a password in the ->set()
call will
stop any further username/password checks from being done.
Should this code be abstracted out of IQ.pm? Should it go in Authen.pm
instead, so it can be overridden properly? Is it completely wrong
and should
be thrown out?
--
Jos
Boumans
http://www.linkedin.com/in/josboumans
How do I prove I'm not crazy to people who are?
