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

Ryan tiko at 7sinz.net
Wed Dec 16 01:41:05 UTC 2009


Ryan wrote:
> 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
>
Apologies for not mentioning this previously, but I do have one feature 
request if at all
possible.  My reason for choosing sqlite originally as my database 
backend is that it allows
a 390 character topic length while the mysql option limited it to 255 
characters. (The
max for a varchar field if I'm not mistaken)  The request then is to see 
a larger topic
length supported by the rserv mysql backend.

Thanks again,
tiko


More information about the ircd-ratbox mailing list