View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002184||unreal||ircd||public||2004-11-15 13:51||2015-07-09 19:50|
|Target Version||Fixed in Version||3.2.10|
|Summary||0002184: Support for services account name in /WHOIS|
|Description||Since many services use nick-independent authentication, it would be nice to have the account name shown in /WHOIS. I modified Unreal a bit and added a command SVSACC to set an user's account name. (:prefix SVSACC nick :account)|
It is turnable on/off by (un)defining the macro SUPPORT_NICKINDEP_AUTH. I already modified ./Config, autoconf/configure.in and src/modules/Makefile.in, but if I run autoconf, it doesn't resolve the CHECK_LIBCURL ... m4 macros.
Please take a look at it,
|Tags||No tags attached.|
|3rd party modules|
nickindep-auth.diff (13,291 bytes)
|Sounds like a waste of memory to me...|
Well, that's you can turn it off ;-)
But it's pretty useful (and common) on such networks... since no-one likes to do /ns INFO or similar things.
Why do services need an SVSACC?
SVSMODE nick +r (and do that everytime they change nicks)
SWHOIS nick :is logged in as <account>
Blammo. Though I admit, this would has some interesting complications for netsplits/rejoins, and the only real solution would be to just -r and clear the SWHOIS on everyone coming in from a netsplit and make them reidentify :/ , or implement some really complex form of netsplit tracking... (utilize timestamp/service stamp, et al).
Anyway, if you do want to do it this way, it's better to call it ACCOUNT, because that's what IRCu calls it :P . Easier to understand ;) .
Oh, and sorry to nitpick your patch but...
+ if (MyConnect(sptr) && !IsULine(sptr))
+ sendto_one(sptr, ":%s NOTICE %s :You aren't allowed to do this.", me.name, sptr->name);
+ return 0;
+ if (parc < 3)
+ sendto_one(sptr, ":%s NOTICE %s :SVSACC Syntax: SVSACC nick account-name", me.name, sptr->name);
+ return 0;
+ if (!(0 < strlen(parv) < NICKLEN) || !(subject = find_person(parv)) || !subject->user)
+ /* The jungle of send.c... let's hope this works */
+ sendto_one(sptr, ":%s NOTICE %s :No such user.", me.name, sptr->name);
+ return 0;
You realize there are numerics for those kinds of errors? Also, almost all of unreal's svs* commands simply say nothing for non ulines. Why should this send an error? And finally, realize that normal servers may need to use this for net synching, so it's probably better to just check if the sender is not a server.
That doesn't make sense, ONLY the NICK you are using, CAN be your "account" name.
Otherwise you are NOT registered (and therefore you haven't the +r flag).
You can identify from an other nick, that's right. But you won't have the +r (registered) flag, and you would only use that temporary, so it makes no sense at all.
codemastr said it correctly: Waste of memory and waste of time ;)
Maybe you are talking of the services you're using, but the general treatment is, that if you HAVE an account, you ARE registered. Therefore services set +r.
I don't wanna use SWHOIS, since users which have an extra whois line set still can have an account too... Also, there is a numeric reply specific to an account line. Some users with some clients would be happier with this.
And because using ACCOUNT as command name -- that would be easy to modify, and if services/other ircds use this as command name, it really should be renamed.
Yes my services do it that way.
If your services don't do it that way, then they aren't working as they are supposed to work.
If you register Fips, and identify while you are using the nick Fips|away, and services set +r, they make a MISTAKE, because YOUR away nick is NOT registered !
There is no other way. That's the reason, unreal sets automatically -r, if you switch your nick.
You are comparing it to quakenet, if you authenticate to q, it shows your auth name. Right, Quakenet does NOT have Nickname Services, therefore it makes sense, and not in this case.
There was a reason Unreal supports modules...
Maybe its so users can MAKE commands for their server? It looks like you definatly know C well enough to do this yourself.
||Rocko: so are you saying the only correct form of authentication is that based on nickname? Go tell the srvx coders that. I don't think it's uncommon for a network to not want nickname ownership, but still have some form of account service. Are you going to say that those nets can't use unreal?|
||Right, srvx is made for ircu, and not for unreal !|
if (!(0 < strlen(parv) < NICKLEN)
You might want to learn some C. C does NOT support cascading relational operations in the way you think it does. I'm guessing you wanted that to mean "0 is less than strlen(parv) and strlen(parv) is less than NICKLEN". That's not at all what that does. That statement actually does the following, "is 0 less than strlen(parv, and is the result of that less than NICKLEN." The result is either 0 (false) or 1 (true), so it does:
Is 0 < strlen(parv)?
Is TRUE(1) < NICKLEN?
Is FALSE(0) < NICKLEN?
Now since NICKLEN should always be > 1, this means, as long as strlen(parv) > 0 (and by the way, that is a *horrible* way to do that check), the statement is always true.
What you really want is, (*parv && strlen(parv) <= NICKLEN)
Sure, you're right, C doesn't support x < y < z.
@ codemastr, parts of aquanight's edit:
Well, some things I just derived from other modules. Like strlen(...) > 0 or sending back a "Syntax" message... So please first look at your own source code before running it down, okay?
..and C99/C++-alike mid-code declarations, not to mention that you don't seem to allocate sptr->user->account anywhere so you are writing to some random memory location *cough cough*.. :p. And some other issues (like in Makefile @ COMMANDS= you suddenly add m_svsacc.so instead of .o), etc...
BUT besides all these things (since this is all just implementation stuff)...
If I understood it correctly, what you suggested is not useful for anope/ircservices/auspices(?)/etc networks, but only for non-nick-registration networks etc, right? If so, then I don't see a lot of use in it either.
I guess you wanted to submit a complete-ready-patch to us, that didn't cause any problems if not used, and saving is from having to do pretty much anything (coding) but hmm ;).
codemastr: what's your opinion (eg: pro/cons) on this if it would be implemented with all bugs mentioned above fixed and making it a config.h option instead of ./Config.
What I see is:
PRO: a feature that might be useful to some people.
PRO: They would not have to do patching etc and can still get support.
CON: new code, possible breakage
CON: it takes some space (a few kb ;p) and is rarely ever used (<.5%)
CON: the above could also be a less technical reason: if something is rarely ever used, should it even be included? ("keep the code clean"-alike argument)
Another more general question is : if we don't find a feature useful, should it be included anyway if we get a ready-made-patch? :p.
My answer to that would be 'no' ;).
But then again, this feature can be useful in some rare cases, so this doesn't necessarily apply to this :P.
[I guess all of the above is more kind of a summarization but.. ;p]
>There was a reason Unreal supports modules...
>Maybe its so users can MAKE commands for their server? It looks like you definatly know C well enough to do this yourself.
Slight problem there, this requires data be stored in the user structure. Until coders figure out a way for non-permanent modules to be able to store data through a rehash (though I'd just say modules needing extra data should just be permanent), this would be quite difficult to pull off as a module.
*edit* user structure, not aClient... probably close enough though :/
||hm this is in 3.4.x and I think in 3.2.10 too|
|2004-11-15 13:51||Fips||New Issue|
|2004-11-15 13:51||Fips||File Added: nickindep-auth.diff|
||Note Added: 0008327|
|2004-11-15 14:26||Fips||Note Added: 0008329|
|2004-11-15 14:26||Fips||Note Edited: 0008329|
|2004-11-15 21:55||aquanight||Note Added: 0008334|
|2004-11-15 22:03||aquanight||Note Edited: 0008334|
|2004-11-16 05:40||Rocko||Note Added: 0008339|
|2004-11-16 10:12||Fips||Note Added: 0008340|
|2004-11-16 10:13||Fips||Note Edited: 0008340|
|2004-11-16 12:45||Rocko||Note Added: 0008341|
|2004-11-16 13:23||Stealth||Note Added: 0008342|
|2004-11-16 13:28||aquanight||Note Added: 0008343|
|2004-11-16 13:35||Rocko||Note Added: 0008344|
||Note Added: 0008347|
|2004-11-17 09:06||Fips||Note Added: 0008357|
|2004-11-17 10:46||syzop||Note Added: 0008358|
|2004-11-17 14:57||aquanight||Note Added: 0008359|
|2004-11-17 14:58||aquanight||Note Edited: 0008359|
||Status||new => feedback|
||Relationship added||child of 0003284|
|2015-07-09 19:50||syzop||Note Added: 0018459|
|2015-07-09 19:50||syzop||Status||feedback => closed|
|2015-07-09 19:50||syzop||Assigned To||=> syzop|
|2015-07-09 19:50||syzop||Resolution||open => fixed|
|2015-07-09 19:50||syzop||Fixed in Version||=> 3.2.10|