Provide framework/library to writing custom login handlers #550
Comments
LukasKalbertodt
added
kind:new-feature
|
While I'm for deno in all fairness it should be said that in production you are still going to want to cache the dependencies locally. One could additionally provide a |
|
Deno does cache these dependencies automatically: https://deno.land/manual@v1.25.2/linking_to_external_code |
|
It also recommends vendoring them manually for production, though: https://deno.land/manual@v1.25.2/linking_to_external_code#but-what-if-the-host-of-the-url-goes-down-the-source-wont-be-available EDIT and if you want verification à la |
|
So... Deno currently has no stable option to listen on Unix sockets. We need that for our test deployment, so unfortunately, Deno is out for now. Will go with Node for now. |
|
Just my few cents here: Not a hard no, but I'm actually against deno Not only is it uncommon and therefore harder to run, the goal here is to have something users can easily modify and feel comfortable with. In a lot of cases, these users are also less actual developers, but SysOps and/or DevOps people. Cool new stuff people are unfamiliar with is therefore what I would rather avoid if at all possible. In fact, Python is far more common among DevOps/SysOps and would be my first choice. But node is well established and still okay. |
…etup & test deployments (#645) Closes #550 See the referenced issue for motivation. Can be reviewed commit by commit, but reviewing all in one isn't bad either. As you can see from the changes, our framework does more than the previous `login-handler.py`: it sends the `POST /~session` request to Tobira itself. That means no `X-Accel-Redirect` magic is needed, making the nginx simpler. The main part is done, but this is still a draft for a number of reasons: - [x] Decide on name and scope for the NPM package. -> `@opencast/tobira-authkit` - [x] We want to potentially also implement `auth.mode = "opencast-users"`. In that mode, Tobira would handle `POST /~login` requests itself by just asking Opencast if the login data is correct. That should be fairly easy to do. And I think it's very useful: it's _the_ obvious auth system Tobira should support and I assume quite a few institutions want to use it. Further, even if an institution wants a different auth system in the long run, just using Opencast users is a very simple way to get everything running. Without auth system, you only see an empty Tobira which is quite underwhelming. So this would drastically improve the "first setup" experience IMO. - [x] ~~I also noticed that we might want to simplify login handlers even more by adding yet another mode. In that mode, Tobira would forward `POST /~login` requests to a configured HTTP service which would send back appropriate auth headers. This is little work in Tobira and that way, the nginx config could be a lot smaller still, again making it easier to set up Tobira.~~ -> I still think it's useful, but we won't do it now. - [x] Once all the previous points are decided: update docs appropriately. -> Done with NPM package name `@tobira/authkit` for now. So yeah, I'd like to talk about the two additional auth modes and whether we want them. Of course they could be implemented in a separate PR. But it would also be nice to only needing to rewrite the docs once.
While flexible, Tobira's login system requires quite some setup. To make it easier for adopters to get started and save everyone's time, it would be nice to have a good starting point for writing such a login handler. (This issue is purely about login handler, i.e. using Tobira's login page and session management.)
In our test deployment we use
util/containers/login-handler.py. My first idea was to just extract the common plumbing code as a Python module. Unfortunately, I forgot thathttp.serverhas this note: "Warning:http.serveris not recommended for production. It only implements basic security checks" (link). It's not clearly described why this warning exists or whether it applies to us. But I guess it would be better to not tell Tobira users to use such a script.It's rather inconvenient to code this logic in the webserver config directly. And most people would feel more comfortable coding some Python or another well-known language instead of weirdly (ab)using a webserver config. I see three viable options:
Python + a proper HTTP lib. Unfortunately, such a lib is not included in the standard library, meaning we need some external lib that needs to be installed with pip or something. Not a huge problem, but less convenient than having it in std.
JavaScript + Node. It's really easy to get a simple HTTP server going with Node. And it's easy to install Node on most systems, or it's possibly already installed. JS is a very common language, so most people would feel comfortable enough using it.
JavaScript + Deno. Deno is the new JS runtime in town, made from lots of Node devs that wanted to do it "right this time". Apart from many other cool features, for us there are mainly two advantages: (1) it can execute TypeScript directly, so we can just write our lib/framework in TS, having one language fewer in our repo (since our frontend is already TS). (2) It supports remote imports, e.g.
import { ... } from "https://.../";, meaning that including our lib would be really easy (without even sayingnpm installor so). The main disadvantage is that it's less common than Node, making installing it on a server slightly harder (tho still easy).I think I would like to use the Deno solution because of having fewer languages in this repo, ease of including our dependency, and trying cool new stuff.
The text was updated successfully, but these errors were encountered: