A template for self-hosting Grist with traefik and docker compose

Showcase
5

Hi Helmut, /auth/login is called if Grist is configured to use forward auth - in other words, if GRIST_FORWARD_AUTH_HEADER is set (see grist-core/app/server/lib/ForwardAuthLogin.ts at 52eb5325c23f1015fd94cd7eed5b66eccff01dce · gristlabs/grist-core · GitHub). You can see the code for the call here:

If you are seeing GRIST_DEFAULT_EMAIL being used, it sounds like Grist isn’t using the forward auth login mechanism, but is still using the default “minimal” login mechanism implemented in grist-core/app/server/lib/MinimalLogin.ts at 52eb5325c23f1015fd94cd7eed5b66eccff01dce · gristlabs/grist-core · GitHub

Can you double check that GRIST_FORWARD_AUTH_HEADER is set, and also optionally GRIST_FORWARD_AUTH_LOGOUT_PATH? If you get it working, I’d be happy to hear about what worked for you.

1 Like
6

Hello Paul,

I think it should be ok. This is my env file:

TZ=Europe/Berlin

APP_DOC_URL=https://grist.example.com
APP_HOME_URL=https://grist.example.com
PORT=8485

GIST_INST_DIR=/persist
GRIST_DATA_DIR=/docs

GRIST_SINGLE_ORG=docs
GRIST_ORG_IN_PATH=false
GRIST_SUPPORT_ANON=false
#GRIST_DEFAULT_EMAIL=services@example.com

GRIST_SANDBOX_FLAVOR=unsandboxed

GRIST_PROXY_AUTH_HEADER=Remote-Email
GRIST_FORWARD_AUTH_LOGOUT_PATH=/signed-out

#DEBUG=1

I’m using gristlabs/grist:0.7.8 Docker image.

If I enable /auth/login only for authentication, pressing sign-in, Grist login with you@example.com and don’t see any /auth/login call.

Thank you and best regards,

Helmut

Edit: Oh no!!! Now I found the problem after looking to your text and my env file. Have always used GRIST_PROXY_AUTH_HEADER, but it’s GRIST_FORWARD_AUTH_HEADER. Now it’s working.

I think I lost 3h of my life last weekend and I think I’m using PROXY because of this thread:

Thank’s for replying. I think I never noted the difference, because the word PROXY makes also sense.

7

Argh, sorry for your pain! These are too easy to confuse.

Glad things are working now at least.

1 Like
8

thanks a lot, it’s working well :grin:
Except for the : Examples & Templates
I have this msg : error: “organization not found”
Should it work ?
And is it normal that when I invite a person(gmail account) with it, no email is sent?

image
image1760×898 38.1 KB

9

The examples & templates link isn’t configured well in self-hosted Grist, we should probably just hide it or have it link to https://templates.getgrist.com/

That’s normal, some configuration would be needed to have a way to send emails. We use sendgrid ourselves, and haven’t built a more general solution yet. There’s a thread about that here: feature request: smtp settings for self hosted installation · Issue #146 · gristlabs/grist-core · GitHub

1 Like
10

One thing to clarify. Regarding SSO. Let’s say you have three apps. All of them use auth on the reverse proxy: grist .example.com, whoami .example.com and whoami2 .example.com. On all of them the reverse proxy catch any /sign-out or /logout call and logout the session.

Following happens:

  • login with user1 on whoami .example.com. result: logged in with user1
  • open in another tab grist .example.com. result: need to press sign-in, no need to auth and also being logged in with user1
  • open in another tab whoami2 .example.com. result: logged in with user1
  • logout on whoami .example.com/logout. result: logged out, forced to login again with Authelia
  • switch to the tab with whoami2 .example.com, reload the page. result: because I’m still logged out, there is also Authelia’s login screen

For now it’s ok. Maybe grist should recognize the email header and don’t need to press sign-in first. But then something strange happens:

  • switch to the tab with grist, reload the page. result: still logged in on grist with user1!

It becomes even more strange:

  • still logged out. now login with user2 on whoami. result: logged in with user2
  • switch to the tab with whoami2, reload the page. result: logged in with user2
  • switch to the tab with grist, reload the page. result: still shows user1 logged in and it’s possible to open documents from user1!

Could this be an error in grist? At least with caddy’s forward_auth implementation, only the /auth/login call send the email header to grist. I think this should be the same with your traefik configuration?

11

Sounds like a cookie needs clearing upon logout. Thanks for reporting!

1 Like
12

Should I create an issue on GH? Thank you.

13

Actually that would be great, just to get the scenario clear with what domains the cookies are being set on, and the treatment of signout urls.

14

Hello :grinning:,
With that docker compose,
how can we install libraries like jinja for example ?
Thanks

1 Like
15

(sorry for not noticing this question here - cross-referencing Install Third-party libraries)

16

Hi @paul-grist !

We are using a traefik + docker setup thanks to your template. I’ve a question about keeping our instance up to date.

The grist-core release policy is not clear to me (I don’t see releases in github), and neither the releases in the Docker hub. What would you recommend for keeping a self-hosted version up to date ? Thanks!

Yohan

17

Hi @Yohan_Boniface, the gristlabs/grist:latest image is generally updated around 6am UTC with the most recent version of grist-core that is passing all tests. At the time of writing, it last updated 2 days ago due to timeouts in the github action that updates it: Actions · gristlabs/grist-core · GitHub. This image is a good one to track to get the latest and greatest version of Grist, although there is some risk of untested behavior breaking.

18

Thanks @paul-grist !

So then there is no versioning scheme around at this time ? (I understand that Docker image is single-tagged “latest” and it runs main git branch ?)

19

We occasionally tag a version, but haven’t become systematic about it yet. gristlabs/grist:0.7.9 is the most recent tagged version, from some months ago (see Releases · gristlabs/grist-core · GitHub). We’ve talked about tagging on roughly a monthly basis. What would be your ideal?

20

Yes, CalVer sounds good!

Either YYYY.MM(-patch) in order to have a regular release (also better for communication), or YYYY.MM.DD(-patch) to make it more flexible and to release when it’s hot and the baker is awake! :slight_smile:

Also, I’d say that having an easy way to know the running Grist version from within the client would very handy to help debugging bugs coming from Mars. :slight_smile:

1 Like
21

@paul-grist two more questions:

  • do you have a recommendation for the RAM on the server ? We hit 1Go yesterday, so we now have passed to 2Go, FYI.
  • do you think it’s possible to have multiple containers running in parallel (i.e. is a running Grist stateless) ? Would that need using PostgreSQL for the “core” db ?

Thanks for your lights! :slight_smile:

22

For the record, we just hit the 2 Go RAM.

23

Hi Yohan, there are some hardware recommendations at Self-managed Grist - Grist Help Center

It is indeed possible to have multiple containers in parallel - we do so in our hosted service - but there’s significant engineering work needed to make this happen. In general for a single organization I’d expect one server with more CPU and RAM to be preferable to multiple lighter servers.

1 Like
24

:warning: Security Update 2023-11-21 :warning:

The original version of the instructions above, combined with a version of grist-core up until v1.1.7, produced an insecure configuration which made it possible for an attacker to impersonate any user on the system.

Please be sure to update grist-core and/or the gristlabs/grist docker image to the latest fixed version (v1.1.8, stable, or main).

This alert also applies to grist-omnibus (docker image gristlabs/grist-omnibus). Upgrading to the latest version will fix the issue.

The issue affected specifically the suggested configuration of grist-core with traefik. If you used a different configuration, you may not be affected.

3 Likes