View Issue Details

IDProjectCategoryView StatusLast Update
0002275unrealircdpublic2006-04-29 09:53
Reporterfez Assigned Tosyzop  
Status resolvedResolutionfixed 
Platformx86OSLinuxOS Version2.4.x
Product Version3.2.2 
Fixed in Version3.2.5 
Summary0002275: cloak algorithm feature request
DescriptionWell, I feel kind of indifferent myself about this feature request, but,
I was writing a custom cloaking module to give every user the same cloaked hostname on +x (I wouldn't use it myself but some other people requested it), and they requested that it be possible to calculate a hidden hostname based not merely on the users's real hostname, but also on their nickname and ident.

However, the API usage is
DLLFUNC char *hidehost(char *host)
so currently there is no way to pass a nickname or hostname to the cloaking algorithm...
So the request is to possibly make this
DLLFUNC char *hidehost(client *cptr, char *host)
or even just client *cptr, since you can access the hostname with one of cptr's members.

I don't feel particularly strongly about this request, but it might be nice to make hostname cloaking a little more flexible.

 -- fez / Eric
TagsNo tags attached.
3rd party modules


child of 0002748 closedsyzop 3.2.5 Release 



2005-01-11 23:57

administrator   ~0008783

Cloaking on nick? Isn't that a bit stupid since it changes if you change your nick. On ident? Uh.. what use has this anyway? :p
Changing the API would also break things, like codemastr has CloakHost that shows the cloaked host for a specified hostname/IP (can be quite useful sometimes) and IIRC I also used it once in my personal modules as well.


2005-01-12 01:11

reporter   ~0008785

yeah you're right, plus there would be potential problems with server-linkings causing hidden host desync, e.g., i connect and set mode +x, then change my nick, then a new server is introduced and it cloaks my host different than the first server....

It's not really worth it in the end, this sort of thing is best left to services.


2005-01-15 13:39

reporter   ~0008818

Actually though, I had been considering a method to allow a sptr to be passed (yes, I have people who want things like as well). Though, I was considering it for different reasons. One of my ideas was something like <hash> for SSL but <hash> for non-SSL (makes it real easy to detect SSL users).

Breaking the API though is a serious issue. We could, however, get around this by adding another callback, say a CALLBACKTYPE_CLOAK_EX which takes the extra param.

Agreed though, for things like /cloakhost, this would be a problem.


2006-04-27 19:23

administrator   ~0011638

Funny enough, this is going to be implemented now.

Yeah, sometimes it takes a while... :P


2006-04-29 06:15

reporter   ~0011655

it seems that it is time to look for another ircd to use :(


2006-04-29 07:27

administrator   ~0011656

I'm lost with regards to how introducing this feature could possibly trigger the decision to change ircds, but hey! have fun :P


2006-04-29 09:53

administrator   ~0011657

Added in .495:

- Module coders: For cloaking, added a new callback type CALLBACKTYPE_CLOAK_EX (which replaces
  CALLBACKTYPE_CLOAK). This passes 'aClient *sptr, char *host' instead of only 'char *host'
  to the cloaking module, which can be useful if you need to cloak on something other than
  IP/host. Suggested by fez (0002275).
  Module may still provide only CALLBACKTYPE_CLOAK though, in fact this is what the official
  cloaking module does. So no updating of cloaking modules needed.
  A side-effect of this "extra cloaking" callback is that we needed to change make_virthost()
  which now has an extra parameter in front, and another side-effect is that calling the
  CALLBACKTYPE_CLOAK may not work since only *_EX might be available. To my knowledge there
  are very few modules (only 1 I know) that will have a problem due to this, so sounds like
  an affordable tradeoff.

Issue History

Date Modified Username Field Change
2005-01-11 23:46 fez New Issue
2005-01-11 23:57 syzop Note Added: 0008783
2005-01-12 01:11 fez Note Added: 0008785
2005-01-15 13:39 codemastr Note Added: 0008818
2006-04-27 19:23 syzop Note Added: 0011638
2006-04-27 19:23 syzop Assigned To => syzop
2006-04-27 19:23 syzop Status new => assigned
2006-04-27 19:23 syzop Relationship added child of 0002748
2006-04-29 06:15 pinstrate Note Added: 0011655
2006-04-29 07:27 syzop Note Added: 0011656
2006-04-29 09:53 syzop Status assigned => resolved
2006-04-29 09:53 syzop Fixed in Version => 3.2.5
2006-04-29 09:53 syzop Resolution open => fixed
2006-04-29 09:53 syzop Note Added: 0011657