Devlog #2

TL;DR

Friends can now be invited directly from a room. A toast notification allows accepting or declining the invite. A new admin page was added to manage users, including role changes and banning. Spielo is now publicly available on GitHub, and a demo version is online.

Direct Friend Invites

I implemented a feature that allows inviting friends directly from within a room.

For this, I created a new socket event invite_friend, which is emitted by the client when a button is pressed. The button only appears if the friend is online and the user is currently in a room, since the friend overlay can be accessed both from the lobby and from within a room.

On the server side, several validations are performed:

• rate limiting (3 invites per 5 seconds)
• user must be online
• user must not already be in the same room

If all conditions are met, the invite is sent via the friend_invite event. The sender also receives a confirmation that the invitation was successfully delivered.

The receiving user sees a toast notification (inviteToastContainer) that stays visible for 15 seconds. They can either accept or decline the invite. Accepting the invite automatically moves them into the room, while declining simply closes the notification.

This significantly improves usability, as users no longer need to manually share room codes.

Admin Page

I created a new admin page to manage all registered users.

The admin section is placed in a separate admin folder with its own index.html, keeping it isolated from the main client. This improves the overall project structure and separation of concerns.

In userService.js, I added three asynchronous functions:

• updateUser(userId, newRole, isBanned)
• getAllUsers()
• getBannedStatus(userId)

The admin page includes a simple authentication check using a JWT token and user ID stored in localStorage. The server verifies whether the user has the admin role before returning sensitive data.

The client renders a table sorted by created_at. It displays:

• user_id
• username
• role
• is_banned

Additionally, two actions are available:

• toggle role between user and admin
• ban users by setting is_banned

A protection mechanism was added to prevent users from modifying their own account (e.g., self-demotion or self-ban).

Ban Check

To make is_banned effective, a ban check was added during login. Users with a banned account are now prevented from logging in.

Additionally, if a user is already authenticated (valid token stored in localStorage), the server rejects the token if the account has been banned.

However, automatic logout for already active sessions still needs to be implemented.

Documentation, GitHub & Demo Website

The remaining time was spent improving documentation. The README was rewritten (a preview GIF is still missing), and the repository was made public.

A separate demo environment was also created to avoid exposing my private one for testing purposes.