[ircd-ratbox] ratbox-services and database hooks, where to begin.

Lee H lee at leeh.co.uk
Tue Dec 15 22:50:05 UTC 2009

On Tue, Dec 15, 2009 at 04:35:26PM -0500, Ryan wrote:
> The motivation behind this is to allow login authentication
> automatically, on the web
> or IRC side when a user autheticates for the other, as well as
> automatic registration for
> the service opposite the one registered through.  Hopefully, that
> clarifies things.

Again, I can only speak for rserv here -- I'm not entirely sure what you'll
be able to do within Drupal, but I can say that PHP is a hell of a lot
easier to code than C is.  The below will certainly presume you have a basic
understanding of SQL to obtain information from the rserv database.

Allowing authentication between the two will be exceptionally difficult.  An
irc client and a web browser don't actually have any real information in
common other than the users IP address, and there are an awful lot of
situations where even that isn't true -- or isn't secure.

Linking rserv accounts to Drupal accounts should be possible though, see

> To reiterate, and for my own understanding, if the mysql backend is
> shared between
> my CMS and services, the entire process should be a little easier?

The basic premise is this: if rserv and Drupal use the same mysql server
(but their own database on it), then within Drupal, you can actually go into
the rserv database to get the information you want.  You should be able to
trust in nearly all situations that what rserv holds in RAM is stored
correctly in the database.

You can't update or change any of the information (you need to use hooks for
that), but looking at the information and making decisions based on it is 

So if in Drupal you want to find out if a username is registered, what you
do is you have Drupal actually go into the rserv database and have a look in
the 'users' table there to see if there is an account with the given
username.  You can then go on to find other information, such as a hashed
copy of the users password -- what channels they're members of, etc.

If they don't use the same infrastructure, you have to create some mechanism
for Drupal to get information out of the rserv database -- and some mechanism
for rserv to push information back to Drupal.  That may or may not be easy
depending on the approach -- but sharing the same infrastructure is
likely a lot easier for you.

> I have not had enough time to begin understanding the process behind
> the hooks within
> services and would appreciate some light on that as well.

I'm going to presume you're thinking about database hooks here.  The
standard rserv hooks are unlikely to be something you want -- they basically
expect you to add blocks of C into the core of rserv itself, which can do
specific actions when some event is triggered.

The database hooks are what allow external programs to 'change' what rserv
actually holds in RAM, (at which point rserv will then update the database

The rserv database has a special set of tables, which it expects external
programs to be adding rows into.  rserv looks at the content of the rows,
and performs internal actions based on them.

So for example, if you wanted to instruct rserv to register the username
'test1', with the password 'pass1' (which is hashed to
$1$vRe.Flii$c1peHVbtstX53Zvrg1xBD1) and the email address
'test at example.com', you would add the following row into the users_sync 
table in the rserv database:

INSERT INTO users_sync (id, hook, data)
VALUES(NULL, 'REGISTER', 'test1 $1$vRe.Flii$c1peHVbtstX53Zvrg1xBD1 test at example.com);

Every 15 minutes (currently, I'm happy to make it configurable), rserv 
will run a check for new entries in the users_sync table -- when it 
finds one, it looks at the parameters, and then does what it needs to.

I don't mind making some adaptations to the hook system, for example if
you'd prefer rserv to mark rows in users_sync as 'complete' or 'error' for
example so you can track them back in Drupal.  It should also be possible to
shorten how often rserv checks for 'database hooks', in order for Drupal to
then wait and see whether the users_sync entry for example completes

Have a think over what you want, and whether that's likely to achieve it..


-                 Lee H // anfl
-        I code, therefore I break things.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.ratbox.org/pipermail/ircd-ratbox/attachments/20091215/1ee7cc3c/attachment.pgp>

More information about the ircd-ratbox mailing list