AW: Re: [IRCServices Coding] Associating NickGroupInfo with twonicksatonce

Georges Berscheid georges at
Sat Apr 26 02:54:37 PDT 2003


since services are a almost-regular server linked to your network, they
know all of the network-relevant information, including /list. Just use 

Channel *chan;
for(chan = first_channel(); chan; chan = next_channel()) {
    <your code>

to get a list of all channels. There are similar commands for users,
registered channels, registered nicks etc. Note that chan->users is a
linked list of all users currently in the channel. Refer to channels.h,
users.h, modules/nickserv/nickserv.h and modules/chanserv/chanserv.h for
more information on structs.

I suggest you have a look at in
modules/httpd/accesslist.c. This is an example of how to dynamically
include the accesslist of all registered channels into a php-script.
Another example is modules/httpd/banlist.c.
modules/nickserv/dbsynch.c shows how we linked services to the mysql
database. This could also be a possibility, to write all information you
need in constant intervals into a mysql table which you can read with
you php script anytime you want. Choose what fits your needs the best


-----Ursprüngliche Nachricht-----
Von: ircservices-coding-bounces at
[mailto:ircservices-coding-bounces at] Im Auftrag von
Craig Edwards
Gesendet: Freitag, 25. April 2003 23:01
An: IRC Services Coding Mailing List
Betreff: Re: Re: [IRCServices Coding] Associating NickGroupInfo with

Good idea. We're taking the opposite route, only allowing users to
register on irc. We believe that on our network, given the option to
register on the website would create a whole bunch of pointless
never-used nicks that are just used by clueless web users who have no
idea what theyre doing with irc ;-)

We're using our service to fetch certain information that is particular
to the ircd and not services, e.g. output of /list, etc, so if there was
a way to output this too -- i noticed chanserv only keeps a linked list
of *registered* channels, which is the reverse of how our modified
statserv works :)

Anyhow, have fun,
Brain :-)

>we disabled all /ns {register|drop|link} etc. commands in services and 
>force our users to register their nicknames via a web-interface (90 of 
>our users use a java-web-interface to chat anyway). Services have a 
>module that connects to the MySQL database and retrieves information 
>from there, without needing any interaction of bots with services.
>To retrieve services-internal information, we use http-modules which 
>output simple PHP-scripts that can be included using <?php 
>include("") ?> Again, you won't need

>a bot that connects to your network, use any (possibly exploitable) 
>commands and parse the output.
>Craig McLure wrote:
>>Could you give any other suggestions on how this could be done? I'll
go into a few details on what is trying to be accomplished...
>>For years now, people have been acking for use of MySQL databases, so
that they can have "Web Interfaces" to services, basically, we are
creating a module that allows this "su" type command, which will allow
use of the command from specific hosts to gain information on nicknames,
then parse them into HTML, and be able to display on a website.. it
would also be allowed to change some settings on the nickname (example,
access lists, passwords) without having to talk to the service itself.
>>Theres an alpha running at
>>Currently, you need to have a registered nickname on
to use it.. If you wanna try exploiting it in some way.. feel free :p
>>So yeah, any other solutions would be great :)
>>Craig McLure - Craig at
>>ChatSpike - The users network:  
>>InspIRCd - Modular IRC server:
>><`RaSh> how do i install linux i got the cd and i dont see the
setup.exe or install.exe
>>============ Original Message ============
>>>From     : "Andrew Church" <achurch at>
>>>Reply-To : ircservices-coding at
>>>To       : ircservices-coding at
>>>Subject  : Re: [IRCServices Coding]  Associating NickGroupInfo with
two nicks atonce
>>>Date     : 2003-04-23
>>>    The code currently assumes that at most one user will be
>>>with any particular nickname, that NickInfo.user will point at the
>>>with nickname NickInfo.nick, that will point at the NickInfo
>>>nickname User.nick (or NULL if the nickname is not registered), and
>>>User.ngi will point to a nickname group containing (or NULL
>>>NICKGROUPINFO_INVALID).  Breaking any of these assumptions will
>>>cause many weird and dangerous things to happen.
>>>    Note that two or more users can be associated with a single nick
>>>(if, for example, someone has two clients open and using two linked
>>>However, if the user's nick is not in NickGroupInfo.nicks[], things
>>>probably break.
>>>    I'd strongly suggest finding another way to accomplish whatever
>>>trying to do without an "su"-like command.
>>> --Andrew Church
>>>   achurch at
>>>>Hi, we're writing a module which allows a web interface to "su" to a
nickname, similar to the way the unix "su" command (dont ask! :)) heres
how it works:
>>>>basically, /msg somepseudoclient su <nick> <pass>
>>>>..and you gain the privilages of that nick, wether or not they are
using it at the time. What we're doing at the moment is associating the
user's ngi and ni fields with the nickgroupinfo of the registered
nickname, e.g.
>>>>NickInfo* MyNickInf = get_nickinfo(somenick);
>>>>NickGroupInfo* MyNGroupInf = get_ngi(MyNickInf);
>>>>u->ngi = MyNGroupInf;
>>>>u->ni = MyNickInf;
>>>>/* user u is now logged in with privilages of "ngi" nick, send +r as
a raw if neccessary */
>>>>sorry for any errors in this code, im typing it off the top of my
>>>>Basically, the problem we have is, that only one nick can have
"ownership" of a groupinfo at any one time, if we associate user 'u'
with MyNGroupInf, then if some other user online at the time (lets call
them u2) has this same association (u2->ngi == MyNG
>>>>roupInf) than u2 is logged out (and has to re-identify using /msg
nickserv identify <pass>). Basically we cant give two people ownership
of the same nickgroup at the same time. Is there any way we can get
around this, e.g. by memcpy'ing the NickGroupInfo?
>>>>The ownership of the nick by the second user only needs to be
temporary, until disconnect, so there shouldnt be any corruption of
services DB's by having two people pointing at the same nickgroup in the
file, or anything as weird as that :)
>>>>If theres any way to solve this problem simply, without needing andy
to rewrite the core, or for us to approach the problem a different way,
we'd be grateful of anyone could tell us how :)
>>>>ChatSpike Services-dev
>>>To unsubscribe or change your subscription options, visit:
>>========= End of Original Message =========
>>To unsubscribe or change your subscription options, visit:
>To unsubscribe or change your subscription options, visit:

To unsubscribe or change your subscription options, visit: