Vehicle registration system

This document outlines the design specs for the Hackspace vehicle registration system.

The registration system will have the following pages:

• Landing page listing registered vehicles with options to delete or add vehicles.
• Vehicle delete confirmation page.
• Vehicle registration flow.
• Admin search page.

The landing page should provide a button to add a new vehicle, along with cards listing existing vehicles. The cards should list the vehicle registration, some metadata such as make and colour, when it was registered, and a delete button.

The delete page should display the same information as the card along with a delete button. The delete should probably be a POST submission.

This page should check that the vehicle is registered by that member, or the member is an admin. A 404 error should be shown otherwise.

The vehicle registration flow should have two pages. A page to enter your registration, and a page to confirm the details. The confirmation page should use the gov.uk VES API to check the registration is valid and show metadata about the vehicle.

We should rate limit the registration attempts per-member to avoid getting rate limited by the VES API.

This should allow admins to search for vehicles by registration (partial registration?). For now we can limit access to this to the Committee and Director groups (until we implement group inheritance).

Displayed results should use the same card design that members would see.

This is still a WIP, but here's the tentative plan.

Authentication shall be done through a cookie containing a signed JWT. This can be done on every request to avoid having to perform any manual session management. Normal JWT validation rules should apply. The aud field shall contain the member ID, and the name field contain the member's chosen name (as seen on the forum for example). The signing public keys can be found at a .well-known/jwks.json URL. These can be cached by the application.

We will probably create an iFrame to refresh the auth cookie periodically while the page is active. The application should embed this iFrame in every page.

The member's groups can be found in the groups claim as a list of strings.

The template/style files can be borrowed from another application. The most complete currently is probably the Email service (Codeberg). This is currently built in Jinja, but should be trivial to convert into another engine.

We should avoid repeat calls to the VES API if possible. Implementation suggestions welcome.

One approach could be caching the result. This is probably easiest done with a database record containing the registration, fetch timestamp, and metadata. We should probably cache this data forever, but run a daily/weekly task to delete records that are no longer registered to a member.