-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
adding a custom string on the URL #14
Comments
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
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
Would result in a service at:
http://127.0.0.1:8080/index.html
but
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).
The text was updated successfully, but these errors were encountered: