[IRCServices Coding] Associating NickGroupInfo with two nicksatonce

Craig Edwards brain at brainbox.winbot.co.uk
Fri Apr 25 14:09:51 PDT 2003


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 :-)

>Hi,
>
>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("http://your.services.host/moduleurl") ?> Again, you won't need 
>a bot that connects to your network, use any (possibly exploitable) 
>commands and parse the output.
>
>Georges
>
>
>
>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 http://www.chatspike.net/?page=ircadmin
>>Currently, you need to have a registered nickname on irc.chatspike.net 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.net
>>ChatSpike - The users network: http://www.chatspike.net  
>>InspIRCd - Modular IRC server: http://www.inspircd.org
>><`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 achurch.org>
>>  
>>
>>>Reply-To : ircservices-coding at ircservices.za.net
>>>To       : ircservices-coding at ircservices.za.net
>>>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 associated
>>>with any particular nickname, that NickInfo.user will point at the user
>>>with nickname NickInfo.nick, that User.ni will point at the NickInfo with
>>>nickname User.nick (or NULL if the nickname is not registered), and that
>>>User.ngi will point to a nickname group containing User.ni (or NULL or
>>>NICKGROUPINFO_INVALID).  Breaking any of these assumptions will probably
>>>cause many weird and dangerous things to happen.
>>>
>>>    Note that two or more users can be associated with a single nick group
>>>(if, for example, someone has two clients open and using two linked nicks).
>>>However, if the user's nick is not in NickGroupInfo.nicks[], things will
>>>probably break.
>>>
>>>    I'd strongly suggest finding another way to accomplish whatever you're
>>>trying to do without an "su"-like command.
>>>
>>> --Andrew Church
>>>   achurch at achurch.org
>>>   http://achurch.org/
>>>
>>>    
>>>
>>>>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 head.
>>>>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 :)
>>>>
>>>>Thanks,
>>>>Brain
>>>>ChatSpike Services-dev
>>>>
>>>>
>>>>
>>>>------------------------------------------------------------------
>>>>      
>>>>
>>>------------------------------------------------------------------
>>>To unsubscribe or change your subscription options, visit:
>>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>>>.
>>>    
>>>
>>========= End of Original Message =========
>>
>>
>>
>>------------------------------------------------------------------
>>To unsubscribe or change your subscription options, visit:
>>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding
>>
>>
>>  
>>
>
>
>
>------------------------------------------------------------------
>To unsubscribe or change your subscription options, visit:
>http://www.ircservices.za.net/mailman/listinfo/ircservices-coding