SDSM:Future Changes

This document consists of multiple parts; for a directory to all of the parts, see SDSM:Index.

Description

This part of the SDS Modernization (SDSM) document enumerates a non-exhaustive list of perceived unresolved deficiencies in SDS, perceived by Darren Duncan if by whom is not otherwise specified.

This includes intended but as yet unimplemented features, design flaws, broken behavior, poor performance or inefficient use of resources, known security vulnerabilities, out of date dependencies, and suggestions for other kinds of improvements.

Items in this part will be replaced with ones in the Historical Changes part when they are rectified and hence are no longer an ongoing concern.

RETURN

SDS Laravel: Fixes to Broken Behavior

2024 May 15: Timeout Feature Heavy Server Use

SDS Laravel has a security feature such that if a user is inactive for a period of time, 15 minutes typically, they will be automatically logged out of the app. The app displays a countdown timer on the top right hand corner of the screen that ticks for every second of activity, which is valuable for users to know at a glance how much time they have left.

The user doesn't see a logout take place immediately, rather the timer just says "EXPIRED", but when they click on a link afterwards they will be taken to the login screen instead of the normal destination. (And between those 2 events, the main menu bar will also silently fail to display submenus.)

As defined in the source code file resources/views/layouts/main.blade.php, the app considers any of the following user interface (UI) events in a client web browser against any screen element to be evidence of continued user actiity:

   mousemove click mouseup mousedown
   keydown keypress keyup submit change
   mouseenter scroll resize dblclick

Javascript code running in the client web browser will reset the countdown to the full amount whenever one of those actions occurs, for example, when the user merely moves their mouse over the web page or scrolls the page, and not just when they do something more active like typing in a form or clicking a link to load a new page.

Another effect of any of those UI events is that the web client will make a new web server request, invoking the /session endpoint, which informs the server actively that the user is still active, and the countdown timer that the server effectively has for the user is also reset to the full amount. This server call happens at most once every 1 second of what the client considers considered user activity, meaning that merely moving the mouse over the web page causes the server to be invoked once every second by this user, while they remain on the same screen.

For wider context, typical simple web implementations of a security timeout are implemented only on the web server, and they only kind of activity they count is when the user loads a page, such as by clicking a link, or when they submit a form, or they otherwise invoke an API to accomplish an actual business function like fetching or changing data. In such applications, users who are involved in a longer-running task may have to go out of their way to explicitly tell the server they are still using it, such as by hitting a "save and continue" button on the screen, lest they possibly lose their recent changes by continuing normally when otherwise done. (And in some cases, apps may require still-active users to authenticate regularly.)

SDS Laravel uses a more complicated approach in an effort to be more user-friendly, utilizing the juliomotol/laravel-auth-timeout PHP library, so that more things that the user would consider active use, like just interacting with an open page while not making another server request, counts as their being considered active.

But its current implementation is very flawed. At the least in that the web client is notifying the server every second, which puts a huge unnecessary strain on the server, especially multiplied by all the users, and potentially makes the server less available by orders of magnitude of performing real work. This frequent notifying does not increase security in any way and only in extreme edge cases might allow a user to login less.

It should instead suffice to notify the server at any reasonably longer time interval that is less than the timeout interval, in particular it should be no more frequent than once per minute, if not say once per 4-5 minutes. Once per 4 minutes means if the user does something at least every 5 minutes or so it should register on the server with time to spare.

Another reason the current implementation is flawed, is specific to how it affects developer users using the PHP library barryvdh/laravel-debugbar. This library displays extra information on screen about the last Laravel served page request, such as counting and naming the number of SQL database queries performed, or number of Blade views rendered. The timeout implementation severely compromises the utility of the Laravel Debug Bar, in that, as soon as the user does something innocuous like move the mouse over the screen in order to view this extra information, it promptly disappears as it is replaced by info about the /session server request itself, and the user has to reload the page frequently to try and get back the original useful details. Strictly speaking the Debug Bar remembers all the page loads in a menu, but even trying to choose the useful one from the menu almost promptly vanishes since this action causes another /session hit whose result then takes priority for display again as the most recent activity.

So, the way that timeout server notification occurs needs to be substantially changed in order to both reduce server load by orders of magnitude and to not severely compromise developer users' ability to work. This could involve paying attention to fewer kinds of UI events, such as excluding "mousemove", and it could involve notifying the server much less often for any UI event type.

This also leads into a matter which should have a proper discussion between stakeholders, which is that we should more definitively decide what kinds of user actions should actually be treated by the app as being active usage. This should be as restricted as reasonably possible, and also the timeout intervals should be as short as reasonably possible, so to minimize the chances of a security problem from users leaving their computer unattended while logged in to SDS.

Another relevant discussion is whether and how we may want to add support for different kinds of users to be treated differently, based for example on their privilege levels, as to their timeout intervals, for example those with higher privileges may be best to have shorter timeouts, etc.

RETURN

2024 May 15: Excessive Web Client Memory Use

A frequent client web browser side problem with SDS Laravel, possibly specific to some web browsers such as Safari, is that it has a severe memory leak, such that the web browser process may within minutes of an app screen simply being open, consume several gigabytes of RAM, such as up to about 5-8GB used before the page is automatically reloaded by the browser due to excessive memory use. This problem is not specific to the use of developer user add-ons, since it also occurs in the production instance of SDS Laravel, albeit growing more slowly than an instance with the developer user add-ons, for example to 2.5GB of memory just sitting on the production dashboard screen. It is most likely caused by client-side Javascript. This should be investigated and fixed, although that could be deferred as it may go away incidentally as a side-effect of other work.

RETURN