View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002275 | unreal | ircd | public | 2005-01-11 23:46 | 2006-04-29 09:53 |
Reporter | fez | Assigned To | syzop | ||
Priority | normal | Severity | feature | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Platform | x86 | OS | Linux | OS Version | 2.4.x |
Product Version | 3.2.2 | ||||
Fixed in Version | 3.2.5 | ||||
Summary | 0002275: cloak algorithm feature request | ||||
Description | Well, 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. Thoughts? -- fez / Eric | ||||
Tags | No tags attached. | ||||
3rd party modules | |||||
|
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. |
|
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. |
|
Actually though, I had been considering a method to allow a sptr to be passed (yes, I have people who want things like nickname.blah.com as well). Though, I was considering it for different reasons. One of my ideas was something like <hash>.secure.mynet.com for SSL but <hash>.mynet.com 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. |
|
Funny enough, this is going to be implemented now. Yeah, sometimes it takes a while... :P |
|
it seems that it is time to look for another ircd to use :( |
|
I'm lost with regards to how introducing this feature could possibly trigger the decision to change ircds, but hey! have fun :P |
|
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. |
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 |
|
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 |