This has the problem that failing to get a modification trigger might
lead to corrupted state. The author tested it on their large instance
however and it seems to work very well.
So let's try if anyone hits any problems in the wild
Previously when any user config file was changed all users would be reloaded. This could be very expensive on installations with thousands of users. Since this triggered when any file was changed it would trigger when any user connected which can be quite frequent.
As a side-effect this removes the debouncing. This means that user changes take effect instantly rather than after 1s.
Since there is no longer a 1s delay it is extra important that files are written safely. To this end the `thelounge add <user>` command was updated to write the user file atomically. (The update path already did this.)
irc-framework has a funny fallback where it uses nick + server pw
in the sasl handshake, if account is undefined in the options.
This becomes a problem, as the nick might not actually be the account
(happened for znc users), so we need to set it to an empty object to really
turn it off.
LockNetwork is documented as:
> When set to `true`, users will not be able to modify host, port and TLS
> settings and will be limited to the configured network.
Looking at the view, that also includes the name field (for some reason).
When leaveMessage was added to the defaults, the white list for the LockedConfigNetDefaults
wasn't adjusted.
Rather than playing whack a mole, disallow the documented fields + name and export the rest.
Fixes: https://github.com/thelounge/thelounge/issues/4956
Installing a scoped npm package with thelounge install lead to an error,
because the original split that was used to split the version from the
package, split at the first @ from scoped packages.
The framework may emit messages which do not have a time stamp.
We tried to unconditionally convert the time field, fix that.
The Msg constructor replaces falsey time fields with the current
date so we can also remove the duplication from that codepath.
There's a bunch of sub optimal behavior from our ident server.
For one, it allows user enumeration which we don't really want and it doesn't clean up connections that don't send any data.
Fix that
We only respond once to data, then half-close the connection.
Hence, we should only listen to a single data event as well,
else if the remote doesn't stop sending data we keep trying to
write to the closed write end of the pipe.
Per RFC 1413, The uniquely identifying tuple includes not only the ports,
but also both addresses.
If multiple connections happen to use the same local port number
(which is possible if the addresses differ), the username of the first
is returned for all, resulting in the wrong ident for all but the
first.
By not checking the connection address, the information becomes
public. Because there is only relatively small number of local ports,
and the remote ports are likely to be either 6667 or 6697, it becomes
trivial to enumerate all the users.
Co-Authored-By: Juerd Waalboer <juerd@tnx.nl>
This was flagged as an issue by codeQL
> Server crash [High]
> The server of this route handler will terminate when an
> uncaught exception from this location escapes an
> asynchronous callback.
The auth functions are a bloody mess and need to be cleaned up.
using various callback functions and using variables as pointers makes the logic
hard to follow and hence idiotic to type too, as multiple orthogonal logic paths
are mixed up into one function.
This really needs to be untangled
The publicClient interface is utterly horrific.
It allows any client to inject arbitrary events into the socket.io
event stream.
This should get wrapped into a "plugin" event so that it can get properly
typed, better yet, this should get removed completely.
The sort event bundled networks and channels for no reason at all.
They share none of the actual logic, so combining them just makes
the typing poor but serves no benefit.
