View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002184unrealircdpublic2004-11-15 13:512015-07-09 19:50
ReporterFips Assigned Tosyzop  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
Fixed in Version3.2.10 
Summary0002184: Support for services account name in /WHOIS
DescriptionSince 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,
Fips
TagsNo tags attached.
Attached Files
nickindep-auth.diff (13,291 bytes)
3rd party modules

Relationships

child of 0003284 closedsyzop 3rd Party Module Wishlist 

Activities

codemastr

2004-11-15 13:53

reporter   ~0008327

Sounds like a waste of memory to me...

Fips

2004-11-15 14:26

reporter   ~0008329

Last edited: 2004-11-15 14:26

 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.

aquanight

2004-11-15 21:55

reporter   ~0008334

Last edited: 2004-11-15 22:03

 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 ;) .

*edit*

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;
+ }

and

+ if (parc < 3)
+ {
+ sendto_one(sptr, ":%s NOTICE %s :SVSACC Syntax: SVSACC nick account-name", me.name, sptr->name);
+ return 0;
+ }

and

+ if (!(0 < strlen(parv[1]) < NICKLEN) || !(subject = find_person(parv[1])) || !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.

Rocko

2004-11-16 05:40

reporter   ~0008339

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

Fips

2004-11-16 10:12

reporter   ~0008340

Last edited: 2004-11-16 10:13

 @Rocko:
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.

Rocko

2004-11-16 12:45

reporter   ~0008341

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.

Stealth

2004-11-16 13:23

reporter   ~0008342

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.

aquanight

2004-11-16 13:28

reporter   ~0008343

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?

Rocko

2004-11-16 13:35

reporter   ~0008344

Right, srvx is made for ircu, and not for unreal !

codemastr

2004-11-16 16:29

reporter   ~0008347

if (!(0 < strlen(parv[1]) < 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[1]) and strlen(parv[1]) is less than NICKLEN". That's not at all what that does. That statement actually does the following, "is 0 less than strlen(parv[1], 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[1])?
If yes:
Is TRUE(1) < NICKLEN?
If no:
Is FALSE(0) < NICKLEN?

Now since NICKLEN should always be > 1, this means, as long as strlen(parv[1]) > 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[1] && strlen(parv[1]) <= NICKLEN)

Fips

2004-11-17 09:06

reporter   ~0008357

@codemastr:
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?

syzop

2004-11-17 10:46

administrator   ~0008358

..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]

aquanight

2004-11-17 14:57

reporter   ~0008359

Last edited: 2004-11-17 14:58

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

syzop

2015-07-09 19:50

administrator   ~0018459

hm this is in 3.4.x and I think in 3.2.10 too

Issue History

Date Modified Username Field Change
2004-11-15 13:51 Fips New Issue
2004-11-15 13:51 Fips File Added: nickindep-auth.diff
2004-11-15 13:53 codemastr 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
2004-11-16 16:29 codemastr 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
2007-04-27 06:13 stskeeps Status new => feedback
2007-06-11 16:04 stskeeps 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