View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0001927unrealircdpublic2004-07-06 21:552004-08-22 18:08
ReporterZell Assigned Tocodemastr 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Platform*OS*OS Version*
Product Version3.2.1 
Summary0001927: Add SnoMasks to WhoIs reply for Opers
DescriptionAllow opers to see snomasks?
Add this to the whois.c - right below the code for modes:
if (IsEyes(sptr) && IsOper(sptr))
{
  sendto_one(sptr, rpl_str(RPL_WHOISSNOMASK),
    me.name, parv[0], name,
    get_snostr(acptr->user->snomask));
}

add the RPL_WHOISSNOMASK info to s_err.c and numeric.h at your leisure, I added my own for now to make it work.
Additional InformationAllow opers to see snomasks?
Add this to the whois.c - right below the code for modes:
if (IsEyes(sptr) && IsOper(sptr))
{
  sendto_one(sptr, rpl_str(RPL_WHOISSNOMASK),
    me.name, parv[0], name,
    get_snostr(acptr->user->snomask));
}

add the RPL_WHOISSNOMASK info to s_err.c and numeric.h at your leisure, I added my own for now to make it work.
TagsNo tags attached.
3rd party modules

Activities

codemastr

2004-07-06 23:42

reporter   ~0006914

Thanks for proving why people shouldn't modify Unreal! I'll remember these modifications next time you report a crash.

Your code is utterly broken. Want proof? Connect to server2, /oper up. Now on server1 type /whois oper-on-server2. Notice how the snomasks aren't even close to correct!

Snomasks are NOT sent across servers, and I have no intention of adding that bandwidth overhead simply to report it in /whois.

Zell

2004-07-07 21:37

reporter   ~0006922

Well, I noticed it didnt work across servers... I had hoped that maybe you (or one of the other coders, or someone in the viewing audience) would be able to fix it to only run the SnoMask check if the user you are whois'ing is on the same server as you.

It's quite an ingenious invention, though, I do agree that it would be impractical and wasteful of bandwidth to send snomasks across the network. *sigh*

Hehe, I make so many modifications its not funny... though, most of my crashes happen during the build process (and I use Win32 mind you), so I know that I'm the one that's screwed it up, not the Coders. :-)

aquanight

2004-07-08 00:07

reporter   ~0006923

Actually, something like this would be usable across servers:

/whois oper-on-other-server oper-on-other-server

... same way you retrieve their idle time (and reveal the is a Local Operator status), and anything else :P .

Zell

2004-07-08 11:08

reporter   ~0006925

well, as codemastr said, the snomasks are made so that they arent sent between servers, since they only affect the user who has them set... and the other servers dont need to know that info.... besides, it'd take up bandwidth that doesnt need to be taken LoL =D

though, I was able to make the SnoMask lookup ony happen if the user is local:

change this: if (IsEyes(sptr) && (IsOper(sptr))
to this: if (IsEyes(sptr) && (IsOper(sptr) && MyClient(acptr)) <-- that seemed to work for me, but, another form worked as well:

  if (IsEyes(sptr) && (IsOper(sptr)
    if (!MyClient(acptr))
       return 0;
    else
    {
      rest_of_the_stuff_here
    }

the reason I came up with this is an Oper suggested there be something to go with SvsSno/Svs2Sno that u could check a local user's snomasks and verify:
-That the change was performed (you typed it correctly)
-That they havent changed back their snomasks

aquanight

2004-07-08 13:20

reporter   ~0006933

Last edited: 2004-07-14 19:47

 Well, no. For normal whois it wouldn't be shown for the same reason the idle time/Local Operator isn't shown: your server doesn't know about it.

But when you put the nick twice in /whois, the request is forwarded to the server that the user is on, which does know these things, and would thus send the appropriate replies. An example:
I'm on Server A, SomeOne is on Server B and is a local operator.
/whois SomeOne
SomeOne is [email protected] * Someone!
SomeOne connecting from *@Somewhere.SomeISP.net
SomeOne using modes +ighrxtsz
SomeOne using b.server.net Server B
SomeOne on @#Blah
SomeOne is a Secure Connection
SomeOne signed on 0:00:00 January 1, 1970 (<-- you can tell THAT was made up :P)
SomeOne End of /WHOIS
/whois SomeOne SomeOne
SomeOne is [email protected] * Someone!
SomeOne connecting from *@Somewhere.SomeISP.net
SomeOne using modes +ighrxtszO
SomeOne using snomasks +kscnej
SomeOne using b.server.net Server B
SomeOne on @#Blah
SomeOne is a Local Operator
SomeOne is a Secure Connection
SomeOne has been idle 400 seconds, signed on 0:00:00 January 1, 1970 (<-- you can tell THAT was made up :P)
SomeOne End of /WHOIS

*edit* IIRC, +O will show in the modes for far requests ^_~ */edit*

edited on: 2004-07-14 19:47

Zell

2004-07-14 12:28

reporter   ~0007044

well done, aquanight!

what change did you make to allow it to work on /whois userb userb ?

aquanight

2004-07-14 19:46

reporter   ~0007052

I didn't make any changes. I'm just showing how it would work ;p .

codemastr

2004-07-15 12:57

reporter   ~0007094

Hmm there is one issue with this. It can't use snomask +e. That causes some confusion. Why do you need +e to see modes, but all opers see snomasks?

Zell

2004-07-15 20:40

reporter   ~0007099

hadnt thought of that lol... but that should be logical though... the Eyes snomask gives you the access:

* To see modes
* (new) To see snomasks

or, we could move it to so that only admins get snomask viewing (since normally only admins have operserv RAW access to use svssno/svs2sno)
that would be:
if (IsSkoAdmin(sptr))
right?

aquanight

2004-07-15 21:07

reporter   ~0007105

You could say the same for SVS[2]MODE :P so why do non-admins need to see client modes?

Plus sometimes you have IRCops with Services access... while they don't necessarily/usually have RAW access (heck OperServ RAW is, by default, DISABLED, meaning not even SRAs have it :P), it's possible for them to have this level of access (service admin) but not be an admin IRCd-side.

I had an idea... kind of goes against the RFC a bit (then again, does RFC mention WHOIS <nick> <nick> at all? :O ) and might even be ugly but...
Oper +s +e on ServerA, User with +s +ks on ServerB.
Oper does WHOIS User User
Oper's Server sees that he is +e, and sends WHOIS User User User (3 copies) to User's server.
User's server sees the really long WHOIS request, and understands it's coming from a +e Oper (since server<->server traffic is mostly assumed to be correct :P) and sends the SNoMasks.
For nonopers, it would just send WHOIS User User (or whatever) as normal.

Naturally this means that the 3-copy form shouldn't be accepted from users (and reduced to the 2-copy form automatically? or just reject it?), only servers.

codemastr

2004-07-18 18:47

reporter   ~0007145

Zell, read what I said. That CAN'T be done. And I'm certainly not going to do that 3 nickname thing, that's just a bad idea. It completely ignores what the reason behind specifying the nickname twice, and therefore will further confuse people.

What I'm really thinking is, why have +e even affect usermodes? Why not just show the modes to all opers?

aquanight

2004-07-18 18:52

reporter   ~0007146

>And I'm certainly not going to do that 3 nickname thing, that's just a bad idea.
>It completely ignores what the reason behind specifying the nickname twice, and
>therefore will further confuse people.

Yeah... I was thinking for that to be a server<->server only thing... but I can see where that can become a problem...

>What I'm really thinking is, why have +e even affect usermodes? Why not just show
>the modes to all opers?

Agreed, considering that any oper can just /mode +s +e to see the modes anyway... why not?

w00t

2004-07-18 22:36

reporter   ~0007150

Something that I've thought all along...

Zell

2004-07-19 15:48

reporter   ~0007163

ahh... so take out IsEyes(sptr) from the SnoMask and the UserMode replies? that sounds like a good idea...

syzop

2004-07-25 10:34

administrator   ~0007249

Last edited: 2004-07-25 10:36

 codemastr: *notice assigned* what's the plan? :P
Removing the IsEyes I guess? Looks good.
But how are you going to display the snomasks? Are you going to add yet another numeric to whois (waah!) or just show them after the normal modes (which seems logical IMO)?
*edit*so in RPL_WHOISMODE, text like this: +iowghaAsxNzt kcfFvGqs*/edit*

edited on: 2004-07-25 10:36

codemastr

2004-07-26 01:40

reporter   ~0007250

Syzop, well I was going to add it to the mode line, that seems better than creating a new numeric. The whois mode line doesn't seem like something a client would ever parse, so I can't see changing this as causing any problems.

aquanight

2004-07-26 12:23

reporter   ~0007252

Last edited: 2004-07-26 12:24

 >The whois mode line doesn't seem like something a client would ever parse

(Yup. mIRC shows it in the status window ^_^ even when "Show whois in active" is on, or when using the dialog... don't know about others...)

edited on: 2004-07-26 12:24

codemastr

2004-08-22 18:08

reporter   ~0007415

Added in .120

Issue History

Date Modified Username Field Change
2004-07-06 21:55 Zell New Issue
2004-07-06 23:42 codemastr Status new => closed
2004-07-06 23:42 codemastr Note Added: 0006914
2004-07-07 21:37 Zell Status closed => feedback
2004-07-07 21:37 Zell Resolution open => reopened
2004-07-07 21:37 Zell Note Added: 0006922
2004-07-08 00:07 aquanight Note Added: 0006923
2004-07-08 11:08 Zell Note Added: 0006925
2004-07-08 13:20 aquanight Note Added: 0006933
2004-07-13 18:38 codemastr Status feedback => assigned
2004-07-13 18:38 codemastr Assigned To => codemastr
2004-07-14 12:28 Zell Note Added: 0007044
2004-07-14 19:46 aquanight Note Added: 0007052
2004-07-14 19:47 aquanight Note Edited: 0006933
2004-07-15 12:57 codemastr Note Added: 0007094
2004-07-15 20:40 Zell Note Added: 0007099
2004-07-15 21:07 aquanight Note Added: 0007105
2004-07-18 18:47 codemastr Note Added: 0007145
2004-07-18 18:52 aquanight Note Added: 0007146
2004-07-18 22:36 w00t Note Added: 0007150
2004-07-19 15:48 Zell Note Added: 0007163
2004-07-25 10:34 syzop Note Added: 0007249
2004-07-25 10:36 syzop Note Edited: 0007249
2004-07-26 01:40 codemastr Note Added: 0007250
2004-07-26 12:23 aquanight Note Added: 0007252
2004-07-26 12:24 aquanight Note Edited: 0007252
2004-08-22 18:08 codemastr Status assigned => resolved
2004-08-22 18:08 codemastr Resolution reopened => fixed
2004-08-22 18:08 codemastr Note Added: 0007415