Start converting some enum-like strings to proper enums, plus global reformat

This commit is contained in:
Ian Renton
2026-09-02 08:37:13 +01:00
parent 5a6fc19ab5
commit 606cf1be68
24 changed files with 81 additions and 79 deletions
+10 -15
View File
@@ -2,8 +2,8 @@
Web servers generally serve their pages from port 80. However, it's best not to serve Spothole's web interface directly
on port 80, as that requires root privileges on a Linux system. It also and prevents us using HTTPS to serve a secure
site, since Spothole itself doesn't directly support acting as an HTTPS server. The normal solution to this is to use
a "reverse proxy" setup, where a general web server handles HTTP and HTTP requests (to port 80 & 443 respectively), then
site, since Spothole itself doesn't directly support acting as an HTTPS server. The normal solution to this is to use a
"reverse proxy" setup, where a general web server handles HTTP and HTTP requests (to port 80 & 443 respectively), then
passes on the request to the back-end application (in this case Spothole). nginx is a common choice for this general web
server.
@@ -89,19 +89,14 @@ server {
```
One further change you might want to make to the file above is the `add_header Access-Control-Allow-Origin` statements.
These are what's used on
my own Spothole server to make sure that other third-party web-based software can get the data from my instance, and
applies to any endpoint underneath `/api`. If you want
*your* Spothole instance to be set up the same way, so that others can write software in JavaScript that can access it,
leave this intact. But if you want your Spothole instance to only be usable by scripts running on the web server you
write,
you can remove these lines. (Note that this doesn't stop other people writing *non-web-based* software that accesses
your
Spothole API—the enforcement of cross-origin headers only happens within the user's browser. If you need to lock
your
instance down so that no-one else can access it with *any* software, that's an aspect of nginx or firewall config that
you will need
to find help with elsewhere.)
These are what's used on my own Spothole server to make sure that other third-party web-based software can get the data
from my instance, and applies to any endpoint underneath `/api`. If you want *your* Spothole instance to be set up the
same way, so that others can write software in JavaScript that can access it, leave this intact. But if you want your
Spothole instance to only be usable by scripts running on the web server you write, you can remove these lines. (Note
that this doesn't stop other people writing *non-web-based* software that accesses your Spothole API—the
enforcement of cross-origin headers only happens within the user's browser. If you need to lock your instance down so
that no-one else can access it with *any* software, that's an aspect of nginx or firewall config that you will need to
find help with elsewhere.)
Now, make a symbolic link to enable the site: