1
0
mirror of https://github.com/unrealircd/unrealircd.git synced 2026-07-03 20:43:12 +02:00

Reputation used the score of the WEBIRC IP rather than the end-user IP.

This resulted in high reputation scores for all WEBIRC users.
Reported by DeviL.
This commit is contained in:
Bram Matthys
2020-09-28 17:37:08 +02:00
parent 5286edc0ef
commit f2d49eed04
2 changed files with 30 additions and 14 deletions
+8 -6
View File
@@ -13,20 +13,22 @@ Enhancements:
to ```PONG``` to help fix timestamp issues in KiwiIRC.
Fixes:
* When having multiple text bans (```+b ~T:censor```) these caused an empty
* When having multiple text bans (```+b ~T:censor```), these caused an empty
message.
* Text bans are now no longer bypassed by voiced users (```+v```).
* [Websockets](https://www.unrealircd.org/docs/WebSocket_support) that used
```labeled-response``` sometimes received multiple IRC messages in one
websocket packet.
* The reputation score of [WEBIRC users](https://www.unrealircd.org/docs/WebIRC_block)
was previously the score of the WEBIRC IP rather than the end-user IP.
* ```STATS badword``` was not working.
* When setting a very high channel limit, it showed a weird MODE ```+l``` value.
* The ```LINKS``` command worked, even when disabled via
```hideserver::disable-links``` in the optional hideserver module.
* In some cases ```WHO``` did not show your own entry, such as when
searching on account name, which was confusing.
* Memory leak when repeatedly using ```./unrealircd reloadtls``` or
```/REHASH -tls```.
* When setting a very high channel limit, it showed a weird MODE ```+l``` value.
* [Websockets](https://www.unrealircd.org/docs/WebSocket_support) that used
```labeled-response``` sometimes received multiple IRC messages in one
websocket packet.
* ```STATS badword``` was not working.
Module coders / Developers:
* No changes, only some small additions to the
+22 -8
View File
@@ -480,16 +480,12 @@ ReputationEntry *find_reputation_entry(char *ip)
return NULL;
}
/** Called when the user connects.
* Locally: very early, just after the TCP/IP connection has
* been established, before any data.
* Remote user: early in the HOOKTYPE_REMOTE_CONNECT hook.
*/
int reputation_set_on_connect(Client *client)
int reputation_lookup_score_and_set(Client *client)
{
char *ip = client->ip;
ReputationEntry *e;
Reputation(client) = 0; /* (re-)set to zero (yes, important!) */
if (ip)
{
e = find_reputation_entry(ip);
@@ -498,7 +494,17 @@ int reputation_set_on_connect(Client *client)
Reputation(client) = e->score; /* SET MODDATA */
}
}
return Reputation(client);
}
/** Called when the user connects.
* Locally: very early, just after the TCP/IP connection has
* been established, before any data.
* Remote user: early in the HOOKTYPE_REMOTE_CONNECT hook.
*/
int reputation_set_on_connect(Client *client)
{
reputation_lookup_score_and_set(client);
return 0;
}
@@ -507,9 +513,17 @@ int reputation_pre_lconnect(Client *client)
/* User will likely be accepted. Inform other servers about the score
* we have for this user. For more information about this type of
* server to server traffic, see the reputation_server_cmd function.
*
* Note that we use reputation_lookup_score_and_set() here
* and not Reputation(client) because we want to RE-LOOKUP
* the score for the IP in the database. We do this because
* between reputation_set_on_connect() and reputation_pre_lconnect()
* the IP of the user may have been changed due to IP-spoofing
* (WEBIRC).
*/
ReputationEntry *e = find_reputation_entry(GetIP(client));
sendto_server(NULL, 0, 0, NULL, ":%s REPUTATION %s %d", me.id, GetIP(client), e ? (int)e->score : 0);
int score = reputation_lookup_score_and_set(client);
sendto_server(NULL, 0, 0, NULL, ":%s REPUTATION %s %d", me.id, GetIP(client), score);
return 0;
}