adding a custom string on the URL

[anguelos]

Could there be a optional command line parameter adding a custom string on the server URL so that we can use a single deployment of adora-belle for multiple lectures:

bin/adora-belle -p 8080 -c config.toml

Would result in a service at:
http://127.0.0.1:8080/index.html

but

bin/adora-belle -p 8080 -c config.toml -s lecture1

Would result in a service at:
http://127.0.0.1:8080/lecture1/index.html

This would allow for a very simple way to provide different appointment URLs to different groups of people eg. different lectures.
This use case would make more sense in conjunction with "allow all users" setting and limiting IP address to a specific institution (requiring VPN connection's).

[noctux]

Hello angelos, thank you for your interest in the project!

On Sat, Apr 24, 2021 at 04:38:40AM -0700, anguelos wrote: Could there be a optional command line parameter adding a custom string on the server URL so that we can use a single deployment of adora-belle for multiple lectures: ```bash bin/adora-belle -p 8080 -c config.toml ``` Would result in a service at: http://127.0.0.1:8080/index.html but ```bash bin/adora-belle -p 8080 -c config.toml -s lecture1 ``` Would result in a service at: http://127.0.0.1:8080/lecture1/index.html

Hmm, I see slight problems with this setup: That way, there would be multiple disjunct processes that try to bind to the same port, and try to match different URL local parts (e.g. lecture1/, lecture2), which will not work as usually, a port is owned by a single process, so adding a simple flag won't really help. Initially, I thought about adding support for multiple lectures in a single instance, but that asks the question of ACLs and more complex user-management; unfortunately this was not an option while hastily cobbling things together :P Adding this now would require substantial work and thus take its time. What we personally are doing to run multiple instances is deploying them behind a fronting webserver (apache2 in our case, but others such as nginx, caddy, etc. should be fine, too), which also does the SSL-termination for us. So we have a webroot with subfolders for the different URLs, in your case probably: ``` . ├── lecture1 │ └── .htaccess └── lecture2 └── .htaccess ``` The .htaccesses dispatch to the individual adorabelle instances (one running at port 15001 in that case, so the one for lecture2 should maybe listen on 15002, ...) ``` RewriteEngine on RewriteRule ^(.*)$ http://localhost:15001/$1 [L,P] ``` N.B.: Adora Belle uses semantic HTTP error codes for signaling of errors (e.g. wrong password), so please make sure that your apache does not masquerade those for this proxy-pass, so `ProxyErrorOverride` should be `off`: ``` ProxyErrorOverride off ``` The individual instances are run with a systemd-unit, each with its individual port and config file. Permissions on the config-file can be used to provide access control (i.e.: who may write the config). This solution is not perfect (setup requires some manual steps: choose port, configure .htaccess, copy config file, setup systemd unit; but those could easily be automated with a script), but might be a viable quickfix for your situation as well.

This would allow for a very simple way to provide different appointment URLs to different groups of people eg. different lectures. This use case would make more sense in conjunction with "allow all users" setting and limiting IP address to a specific institution (requiring VPN connection's).

Well, the above setup would allow you to have two instances, with the urls http://example.org/lecture1 and http://example.org/lecture2 automatically dispatching to the correct one. Of course, this does not save you from running multiple processes, but helps by having "meaningful" URLs. What do you think? Best regards Simon