[ejabberd] extauth - does the script need to run continuously?

Jesse Thompson jesse.thompson at doit.wisc.edu
Wed Jul 29 20:02:26 MSD 2009

Belorion wrote:
> I've been playing around w/ extauth for authenticating users against a 
> different datasource - namely via a C# exe that authenticates against a 
> SQL Server database.
> One thing I noticed - only the first user to authenticate against the 
> system worked.  All subsequent attempts failed.  It *appeared* to be 
> caused by the fact that the authenticating executable was terminating 
> after the first authentication.

This can be a problem as your authentication script gets more 
complicated, unstable, or is killed.  There isn't a way to re-spawn the 
script(s).  I also found it to be inconvenient because I wanted a way to 
upgrade the script without restarting ejabberd.

So, I rewrote it as two scripts.  The first one simply loops on input 
and passes the request to the second script (spawned for every request.) 
  As with any extauth script, you wouldn't want to use this if you want 
to scale this massively.

I have included the first script below in case you are interested in 
using it.  You can implement the second script in C# as you see fit. 
The only difference is that the second script doesn't need to loop, and 
you will need to base64-decode the request.

> So, to test this theory, I run the authentication routine in a loop - it 
> sits and waits on input from stdin, processes and authenticates it if it 
> gets data, and then returns to waiting for data on stdin.
> This seemed to "fix" the problem of only authenticating once - but is 
> that the right thing to do?  This seems like it could potentially break 
> if it recieved 2 auth requests super-close together (as in, before the 
> first one was processed).

The requests come in serially (and ejabberd blocks), so I don't think 
that this is a problem.

> Also, I noticed that when I execute the "stop ejabberd" shortcut, the 
> server stops, but the authentication executable continues - *plus*, 
> instead of idling happily at 0% CPU while it waits for stdin input, it 
> suddently spikes to use the 100% CPU (or, in my case, 50%, or all of one 
> core) and just continues like that until I kill it manually.

That sounds like something specific with your executable.  You may want 
to truss/strace/dtrace it to figure out why it is doing that.



use strict;
use MIME::Base64;
use Unix::Syslog qw(:macros :subs);

openlog "authd", LOG_PID, LOG_LOCAL3;
syslog LOG_INFO, "starting up";

my $counter = 0;



     # get the input
     my $request = next_request();
     syslog LOG_INFO, "processing request ($counter)";

     # call the auth script to get the result
     my $result = authenticate($request);
     syslog LOG_INFO, "request ($counter) result is: $result";

     # send the result back

sub next_request {

     # blocking read for incoming requests

     # this code chunk came from the example ejabberd auth script
     my $buf = "";
     my $nread = sysread STDIN,$buf,2;
     do {
     } unless $nread == 2;
     my $len = unpack "n",$buf;
     $nread = sysread STDIN,$buf,$len;

     return $buf;

sub authenticate {

     # encode the request and call the auth script
     # with the request as the argument

     my $request = shift;
     my $enc_request = encode_base64($request);
     $enc_request =~ s/\n//g;
     my $result = `/opt/ejabberd/sbin/auth.pl $enc_request`;
     return $result;

sub send_result {

     # send boolean result back to ejabberd server

     my $result = shift;
     syswrite STDOUT, pack "nn", 2, $result ? 1 : 0;

   Jesse Thompson
   Division of Information Technology, University of Wisconsin-Madison
   Email/IM: jesse.thompson at doit.wisc.edu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3340 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.jabber.ru/pipermail/ejabberd/attachments/20090729/99033585/attachment.bin>

More information about the ejabberd mailing list