Simple access control to Grist-core

Ask for Help
1

Hello!
I have been using Grist now for the last 6 months, and am pretty happy with it. So far, I have been using the desktop version.
Now I’d like to expand with some multi-user applications. I installed the core version under Docker, no problem, it works fine.

But I spent several hours trying to understand in the forum how to handle the login matter, in order to differentiate who is logging in. Technically, that specific part is over my head.

But I am looking at a very simple solution: I work on an off-line network, I have a small menu app which first allows users to log with user/password before accessing the menu itself, the menu just shows on the fly the options a user has access to, I’d like to send a proper request to launch the proper Grist app.

Is there a simple solution for that (via API, or another way)?

Thanks in advance!!
Michel

3

Grist needs an external service to handle authentication. If you are in an offline network, most of our usual suggestions won’t work. In this case, you will need to supply your own authentication provider. There are various options such as Authelia, Dex, or Keycloak.

But it appears that you already have an authentication provider of your own. If it can do OIDC, the suggestions in this page might work as a starting point: OIDC - Grist Help Center

4

Thanks a lot for the very fast answer, Jordi!
I’ll study these options and will let you know.

5

This “external service” can only be OIDC? Is there no possibility of some degraded mode using user/pass combos?

I am in the same situation as michelrev. I’ve been using the standalone AppImage, and I’d like to make it accessible on my home lan so my wife and daughter can also access and make updates. I really don’t want to install an OIDC provider and I’m too much of a privacy freak to use an external one.

Maybe someone knows of an OIDC provider that is dead simple to install and use?

6

No, not just OIDC. We have several options: Self-managed Grist - Grist Help Center

We also have Grist Omnibus, which packages Dex as an OIDC provider.

I have been working on a comparable, experimental packaging that instead uses Authelia.

7

And if you use Gitea you can setup Gitea as OIDC_IDP.

8

Hi Jordi

Thanks! I tried the omnibus (second example in the README), and at first I got an error (“Unregistered redirect_uri” if I recall). Then I looked in the messages that were scrolling by on the terminal and made a blind guess that I should start with http://localhost:9999/auth/login instead of just http://localhost:9999/ and it worked.

(Funnily enough, I’m now unable to reproduce even that error; even http://localhost:9999/ just works now!)

thanks again!

9

Hi Jordi

My previous reply was a bit premature :slight_smile:

When I actually try and hook it up to my already-existing caddy setup, I keep getting this error:

info [grist-omnibus] Checking dex... at https://127.0.0.1:9999/dex/.well-known/openid-configuration debug [grist-omnibus] not ready: FetchError: request to https://127.0.0.1:9999/dex/.well-known/openid-configuration failed, reason: write EPROTO 00F802C794730000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:355:

it keeps repeating.

I also tried your other link but that seems to require a dedicated 443.

Would you by any chance have any hints for someone who already has a few vhosts running behind caddy, and would like to add grist to that setup (i.e., running behind caddy, with caddy doing TLS, including the LetsEncrypt negotiation).

10

Both Omnibus and the grist-pack distribution I’m building expect to handle their own TLS with Traefik. If you already have TLS termination with Caddy, then Traefik is going to interfere.

If you are able to configure Omnibus to not use TLS, you might be able to get it working with Caddy. To do this, I suggest an internal http:// value for the URL variable, to which you will redirect Caddy, and set the HTTPS variable to external. Then, the machine on which Grist Omnibus is running must be able to resolve the http:// URL that you provided. If done correctly, I expect that Dex will be able to resolve that internal http:// URL without TLS trouble.

11

I get

info [grist-omnibus] Checking dex... at http://localhost:9999/dex/.well-known/openid-configuration
debug [grist-omnibus]   not ready: TypeError [ERR_INVALID_PROTOCOL]: Protocol "http:" not supported. Expected "https:"

the config I used is this:

docker run \
  -p 9999:80 \
  -e URL=http://localhost:9999 \
  -e HTTPS=external \
  -e TRUSTED_PROXY_IPS=127.0.0.1/32,172.31.1.100,10.10.10.1,172.17.0.1 \
  -e TEAM=hode \
  -e EMAIL=foo@bar.com \
  -e PASSWORD=topsecret \
  -v /tmp/grist-test:/persist \
  --name grist --rm \
  -it gristlabs/grist-omnibus  # or grist-ee-omnibus for enterprise

If I change the URL to https, I get

info [grist-omnibus] Checking dex... at https://localhost:9999/dex/.well-known/openid-configuration
debug [grist-omnibus]   not ready: FetchError: request to https://localhost:9999/dex/.well-known/openid-configuration failed, reason: write EPROTO 00083D73A2790000:error:0A00010B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:355:

I’m wondering if my Ubuntu 24.04 LTS system has a bad openssl library ??? I have no idea if that is the issue or a red herring.

The README on the grist omnibus repo seems to indicate that this should work (i.e., it specifically mentions “If you run the omnibus behind a separate reverse proxy that terminates SSL, then you should […]” so I will keep trying various things as I find time.

If you can spot something I missed, that would be awesome.

And thanks for all your help, really appreciate it!