There doesn't seem to be a way to catch a 403 Forbidden error opening a
websocket with JavaScript, so this commit changes the behaviour to this:
open the websocket normally, send one "kick" message, close the
websocket.
This should eliminate the possibilty of the websocket-closing background
task closing a newly opened websocket that hasn't yet ponged our ping
(if we have even sent a ping yet).
We now time the interval between consecutive tasks. This is more precise
than using the constant interval the task is supposed to run at since
there is some drift on each run (~0.004s).
Also adds "visibility: hidden;" to `disappear`. It would replace
"opacity: 0;" but Firefox acts weird with only visibility set, it only
half works until you switch between desktop and mobile view. IDK this
isn't that important.
This commit adds a unix socket on which you can receive internal events
as they happen. Currently the only supported event is a chat message
being added. Intended for external applications that depend on chat
messages, e.g. text-to-speech or Twitch Plays Pokémon.
As opposed to just the broadcaster token. This makes the broadcaster
username/password login mandatory, which previously was only mandatory
in the `auth_required` wrapper, but not elsewhere (so for example
leaving comments as the broadcaster was possible with the token only). A
less safe alternative to this would be to compare tokens in `check_auth`
once the Authorization header didn't match.
Also implements stack/queue behaviour where if the eyes limit would be
exceeded, either the new eyes cause the oldest eyes to be deleted OR
the new eyes aren't created at all. The default is the first option.
This commit adds the concept of eyes. One "eyes" is one instance of a
response to GET /stream.mp4. Currently the number of eyes clients can
have is unbounded, but this is a DoS vector.
Previously we only caught FileNotFoundError. If there was a
PermissionError for example, it would have percolated up and
stopped some background tasks.
When you press enter to submit a form and there are multiple submittable
inputs (e.g. type="image" / type="submit"), Firefox chooses the one that
appears first in markup. Before this commit the image input (aka the "I
want a new captcha" button) appeared before the submit button which
meant pressing enter just reloaded the captcha instead of submitting the
comment.
Ensures that if a client becomes idle the segment generator is exited
within a constant amount of time (probably more than this timeout
because of the ASGI server's write buffer and the OS's socket write
buffer, but still constant).
Client and server both close the connection if they don't hear from the
other party after a timeout period. This is a failsafe and should
improve reliability.
Might not be necessary, but if it is then it prevents a sitation where a
websocket is still open but we've forgotten about it, so we will never
broadcast any new messages to it and the client will be practically frozen in
time until they disconnect and open a new websocket.
Also update the user's last_seen when the websocket is closed. This prevents a
user with js enabled who's actually idle being considered absent and being
rotated when their websocket accidentally closes for a few seconds.
This works around a bug in mobile Firefox where under certain cirucmstances two
elements inside an iframe both become the iframe's target elment at the same
time, which breaks the CSS logic so instead of exactly one form being displayed,
nothing is displayed.
Hacky workaround of weird behaviour in Firefox where on a page whose url has a
fragment/hash/anchor in it, sometimes a urlless meta refresh tag will jump to
the element instead of refreshing the page. Same thing happens if the meta
refresh tag's url component is the same as the page's url.
The nojs button appears when the stream is online and the user is not watching.
The js button appears when the stream is online and the media element either
(1) is not using the network or (2) fires an error event.
Matches the behaviour of the js chat. Makes it so if you submit an empty
message but with a correct captcha, you won't be deverified and given another
captcha until you successfully send a message (and exceed the flood threshold).
Previously you could fill in the captcha with no message and be given back a
new captcha, which doesn't make that much sense.
Made the 'Users in chat' header above the overflow area, so it always stays on
top. Now using `visibility: hidden;` instead of `display: none;` to show/hide
messages/users so that nojs css animations don't reset.
This adds a field 'watching' in `user_for_websocket` that's True iff WATCHING,
False iff NOTWATCHING, and None otherwise (since clients don't need to know if
a user is tentative or absent). When the value of this field changes for any
user, they get added to the update buffer (like with any other change).
Removed race condition in `t_sunset_users`: `broadcast_users_update` was being
called *after* a user was removed from memory (and for each user being removed,
which was redundant). In that scenario if there's a user in the update buffer
and `t_sunset_users` wins the race between it and `t_broadcast_users_update`,
then when `t_sunset_users` calls `broadcast_users_update` a KeyError would be
raised since the user's already been removed.
Fixed unintended behaviour of `t_sunset_users`: it was removing users based on
the result of `is_visible`, so users who were actually tenative (as opposed to
absent) were being removed.
This reorders the elements so the comment submit input comes before the
captcha image input (that reloads the form). If a non-submittable input
is active and you press enter, Firefox chooses the first submittable
input and submits the form as if that input were clicked. Before this,
pressing enter on the captcha answer input would reload the form instead
of submitting the comment.
By default the buffer is exhausted every 4 seconds. This should defend against
a potential DoS against clients with JavaScript enabled. Before this, any
request with no token would generate a new user and immediately broadcast the
new user to all the websockets. It's best to lock down as much as possible the
number of places a client can cause the server to broadcasts to all the
websockets.
n9k