View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003233 | unreal | ircd | public | 2007-02-10 18:19 | 2014-01-12 10:58 |
| Reporter | Altor | Assigned To | syzop | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.6 | ||||
| Summary | 0003233: Message to user with wildcard in servername fails | ||||
| Description | When a message is sent as: /msg user@server?.org the error message 'No such User/Channel' is returned, even if a user corresponding to this address exists. Cause: In m_message.c the user lookup code in the function m_message (at the end) was changed (in 3.2.5 I think) to first lookup the server corresponding to the wildcard address, and afterwards to lookup the user. The user lookup doesn't properly take care of server addresses with wildcards (and the same for usernames as well). This causes the server lookup to pass, but the user lookup to fail. | ||||
| Steps To Reproduce | See above | ||||
| Additional Information | Possible fix: Replace the server part of the username with the name of the server found, corresponding with the wildcard For this, a line in m_message.c needs to be added before acptr = find_nickserv(nick, NULL); -> strlcpy(server + 1, srvptr->name, strlen(server + 1) + 1); acptr = find_nickserv(nick, NULL); A problem with this approach is that when 2 servers match a wildcard, and the user is on the second one, this will still fail. A better approach would thus be making the server comparison in hash.c, function hash_find_nickserver() take into account possible wildcards. | ||||
| 3rd party modules | |||||
|
|
I don't really think the "PRIVMSG user@server" was ever intended to accept wildcards, as sending a message in this form insures it gets to the proper user (such as in the case of services, it would be [email protected]), and as such it would be very possible to send a message to the wrong person if someone was impersonating the intended target (such as service@*.your.net, someone can be "service" on any server and receive the message) |
|
|
I don't know what the intended use for this was. All I know is that it worked fine up to 3.2.4. We use this for exactly the situation you describe: to login to our service. We especially liked the possibility to use a wildcard in the server part of the username, because it would make it possible to use backup services servers if needed (serv1.org, serv2.org, ...), and still allow the users to login using a common address (@serv?.org) The service username has been nick banned in the IRCd config file just to avoid the kind of abuse you describe... If you know of any other way to reach this goal, I'd be more then happy to use that :) |
|
|
The PRIVMSG user@server behavior was changed on 3.2.5 for a reason. Maybe this is why its not working anymore. PS: You can always use another services-server with the same servername when your primary services-server fail. |
|
|
vonitsanet: Well, with distributed services you could have multiple up and running slaves, that take over when the master dies?.. |
|
|
Indeed... you can have multiple servers connected at the same time (say, one to each IRCd), and as soon as the one hosting the current services user goes down (or splits off), one of the other ones brings a new services client online to replace it Ofc that introduces syncing issues into the services db's as well, but that isn't really Unreal related anymore :) |
|
|
I think this can be closed |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2007-02-10 18:19 | Altor | New Issue | |
| 2007-02-10 19:26 | Stealth | Note Added: 0013206 | |
| 2007-02-11 14:03 | Altor | Note Added: 0013209 | |
| 2007-02-14 02:43 | vonitsanet | Note Added: 0013215 | |
| 2007-04-27 03:24 |
|
Note Added: 0013773 | |
| 2007-04-27 03:24 |
|
Status | new => acknowledged |
| 2007-04-27 15:34 | Altor | Note Added: 0013894 | |
| 2014-01-12 10:58 | syzop | Note Added: 0017882 | |
| 2014-01-12 10:58 | syzop | Status | acknowledged => closed |
| 2014-01-12 10:58 | syzop | Assigned To | => syzop |
| 2014-01-12 10:58 | syzop | Resolution | open => no change required |
