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

Ryan tiko at 7sinz.net
Wed Dec 16 01:22:18 UTC 2009


Lee H wrote:
> 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
> below.
>
>   
>> 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 
> fine.
>
> 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
> itself).
>
> 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
> correctly..
>
>
> Have a think over what you want, and whether that's likely to achieve it..
>
> Cheers,
>
>   
This is exactly the information I was looking for, thank you!  I was not 
clear whether
I needed to dive into the rserv code.  I have decided that moving the 
rserv database to
the webhost's mysqld is indeed the best route to take and considering my 
installation of
rserv is relatively new, it won't be a big issue.

> 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.
I agree that authentication for each service is going to be very 
difficult.  I do not have
any real hard core experience with C, so it's likely not going to be 
something I could
accomplish right away.  I should not have any issues creating any 
necessary PHP
scripts, however, so I will start simply with synchronizing the users.

> 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.
At this time, 15 minutes is perfectly fine, but could be very useful 
later on.

> 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.
Your suggestion here leads me to believe that entries in users_sync are 
not flushed after
they are added to the main users table, is this correct?  Assuming that 
there were no
errors when adding a user with the register database hook, the new entry 
should be in
the main users table upon the next database update by rserv if I 
understand you.  If that's
true, then I would use that as a means of error checking.  Flushing 
entries from users_sync,
if they are not already being done, would be another method.  I have not 
currently had
a chance to look at the mysql database (I originally chose to use sqlite 
as the backend),
so I could be entirely mistaken.

I will be making time to write the necessary php scripts in the next few 
days and will
report back with any success or failures.  Thank you very much for your 
time and useful
suggestions.

-tiko


More information about the ircd-ratbox mailing list