Skip to main content

September 17

Hi everyone, hope you're well!

Made a good bit of progress on the site in the last two weeks, updates below.

Private Messages: WebSockets (using Socket.IO) implementation

The main functionality is done; private messages now work via websocket and not AJAX polling, which is both a lot more efficient and allows for messages to be displayed in real time.

The security and login flow for the new “messaging server” (a Node.js server for handling websocket connections) is done. This involves the user requesting a login token (a JWT, json web token) via AJAX from the main PHP webserver(s), to prove they are logged in, and then sending that token as authorisation to the messaging server. The token is signed via a private RSA key, rather than a string secret, for added security. A logged in user has one websocket connection, with its own session ID that is stored in their browser’s local storage (so that having multiple tabs open does not mean having multiple connections; they each share the same session ID, so the user doesn’t get the same events multiple times).

Since both the webservers and the messaging servers need to be able to do some of the same functions, such as checking if a user is allowed to message another user, I’ve moved the logic for this from the PHP codebase to being part of the SQL stored procedures for private messages, which involved a bit more complexity than expected in the queries but is working now.

One problem that arose with this implementation is that up until now, Deserted Chateau uses per-request CSRF tokens for security; i.e. it refreshes the CSRF token on every page the user visits (CSRF tokens are basically a method of preventing certain kinds of attacks that can hijack a user’s logged in session). The per-session CSRF approach is overkill for Deserted Chateau as it doesn’t hold e.g. sensitive financial details, and it breaks various important functionality, including both browsing the site on multiple tabs and re-authorising the user’s websocket connection at certain intervals. I’ve changed it to per-session CSRF tokens to solve that, as there aren’t any real security implications in doing so here. Per-session CSRF is the norm anyway; per-request is normally for extremely high security stuff like online banking.

Another benefit of using websockets is that it should allow for some better performance refactoring if needed. Since Deserted Chateau isn’t built using SPA (single page architecture), a user going to a new page can mean several AJAX calls to get their notifications, number of new messages, etc to display in the navbar. Combining the AJAX calls into one is kind of messy code wise, but sending all the relevant information through a websocket request means less server overhead from multiple requests without the messy code, so that’s something to consider.

Styling improvements

Mobile layout

I’ve fixed the search bar at the top of the page from un-gracefully cutting off when the screen is too thin; instead it now grows and shrinks according to the size of the window, to a maximum and minimum size. The Deserted Chateau logo text disappears on smaller screens, leaving just the logo itself.

I don’t expect the site to really be “mobile-friendly”, as that would require a ton of work to make everything be optimally easy to use on small screens, but a responsive navbar is important enough to justify doing.

Video display

Video elements in galleries, and placeholder images for e.g. artworks that exceed a user’s filters, now fade in as other images do. Until now they just appeared instantly, which looked off in galleries that have both images and videos, where some content would fade in and some appeared straight away.

On videos that have a blurred overlay (because of NSFW filters), the video controls are now behind the overlay, preventing their use until the user chooses to click to remove the blur.

I’ve finally decided on a way to properly refactor the code for displaying galleries, which at the moment is a horrendous looking mess, as it contains a ton of HTML inside JS template strings. Instead of that system, I’m making standard HTML5 template items for the different gallery “containers” that house a single artwork submission.

While this doesn’t make the code smaller, it makes it much easier to read and maintain, and makes it more clear what’s going on when gallery containers are created. Due to the logic involved in rendering galleries, it’s also very helpful for the future, as the gallery code for making each element was getting ridiculous to look at. I’m partway through this, there is still some work left to do, but it should be simple enough from here.

Links in large text areas fixed

While implementing the websockets for private messages, I noticed that QuillJS (the library I’m using for rich text content) wasn’t displaying links with the site styling, making them hard to read. Took a little work to figure out, but that’s fixed now.

Next Tasks

This isn’t everything left to do, it’s just the stuff I’m likely to do next.

  • Finish refactoring the gallery code

  • Start implementing the profile sub-pages (e.g. links page, commission info page). With the gallery templates decided, a similar approach should work well for this.

  • Get back to finishing the report and moderation systems

  • Investigate and test making Stripe subscriptions up/downgradable
Back to top