Weblate docker deployment / CSRF-confirmation issue

[ktlhtn]

Hi!

I'm having problems with using Gitlab as a 3rd party authentication service with Weblate deployed with docker. I'm new to docker and docker-compose, so sorry in advance for the noobism :)

If I configure the Weblate container with WEBLATE_ENABLE_HTTPS set to 1, I get an CSRF-cookie not set -error when trying to login to Weblate. This could be the same issue as #1546 which is apparently fixed in the Weblate version 2.16 (?). However the docker image available in docker hub installs version 2.15 (latest available in PyPi).

Is there a way to fix this while using the docker image available in docker hub, with the docker environment file?

[nijel]

This issue is already fixed in the docker container (3cd84530), so what you see is probably something different. Also the CSRF token should be stored in the session, not cookie for the setup used in container (this is supported since Django 1.11), isn't it rather that CSRF token is not set?

What you actually face is probably #1532. I don't plan to backport this to 2.15 docker container, but 2.16 containing the fix should be out quite soon.

[ktlhtn]

Thanks for the reply!

You're correct, the issue I referred has already been fixed in the docker-image I was using. (I only just found the source files used in the weblate docker-image build from the docker-branch ;)). Must be something else then. I'm using a self-hosted instance of gitlab, so the problem might also be in the server end.

Have I understood correctly that using OAuth requires a https connection?

Edit / Additional info:

Don't know if I made it clear in the original post, but the same error message appears when I try to login as the Django admin user, from weblates' own login site. The problem only appears when HTTPS is enabled. The error message I get from the server output / uwsgi is as follows:

2017-08-10 10:11:14,958 DEBG 'uwsgi' stderr output: weblate_1 | [pid: 73|app: 0|req: 2/4] 192.168.4.11 () {40 vars in 613 bytes} [Thu Aug 10 10:11:14 2017] GET /js/i18n/ => generated 6689 bytes in 5 msecs (HTTP/1.1 200) 5 headers in 154 bytes (1 switches on core 0) weblate_1 | weblate_1 | 2017-08-10 10:11:22,338 DEBG 'uwsgi' stderr output: weblate_1 | Forbidden (CSRF cookie not set.): /accounts/login/

[nijel]

So is that with GitLab or password based login (the URL seems to indicate the latter)?

Anyway can you try to log requests in the browser developer tool to see what's really happening?

[ktlhtn]

Yes that happened with the password based login, not GitLab.

When logging in with the weblate password based login the browser only logs the HTTP-POST operation to the url http://server/accounts/login and gets a 403 (forbidden) return value. And the actual error message visualized on the browser is still the same as described above.

When trying to log in via GitLab the browser logs the HTTP-POST operation to the url http://server/accounts/login/gitlab/?next and gets a 403 (forbidden) return value. The POST-call is initiated from http://server/static/js/jquery-1.12.4.js:5168 and the actual error message visualized on the browser is still the same as described above.

[nijel]

The GitLab login issue is #1532 and fixed in git, but I've not seen problems with password logins so far (and it's working fine in all my deployments).

[nijel]

Can you try if 2.16 fixes your issues?

[ktlhtn]

Yeah. I'll update and get back to you!

[ktlhtn]

No difference with 2.16.

Should the container work with only the WEBLATE_ENABLE_HTTPS flag set (nothing else needs to be configured for the container / weblate)? Since you haven't seen this with any other deployments, I'm relatively sure that the problem has something to do with my configurations.

[nijel]

Yes, that should be enough.

BTW: How does the request look like? Do you happen to have http->https redirect and first request going to http and redirecting to https?

[ktlhtn]

There's no attempts to redirect http to https printed in the server/uwsgi output.

When logging in I get two debug messages on the server stderr output (it's the same whether I'm trying /accounts/login or /accounts/login/gitlab):

Forbidden (CRSF cookie not set.): /accounts/login/gitlab/

[pid: 74|app: 0|req: 12/29] 192.168.5.37 () {52 vars in 983 bytes} [Thu Aug 17 06:43:35 2017] POST /accounts/login/gitlab/?next=/ => generated 2947 bytes in 9 msecs (HTTP/1.1 403) 5 headers in 155 bytes (1 switches on core 0)

[nijel]

Ehm, and have you actually configured https for the server? WEBLATE_ENABLE_HTTPS just tells Weblate to use https flag on cookies or on some generated absolute URLs.

[ktlhtn]

By the server do you mean the nginx-instance running inside the container? Do I need an nginx-instance running outside the container? And if you do mean the server inside the container, do you have an example how to configure it? As I said it the first post, I'm not too experienced with docker :) I just assumed that there was some magic happening regarding the server configurations and the http-to-https -redirects I hadn't understood yet. Which of course is kind of true nevertheless. ;P

[nijel]

The weblate container does just http, by setting WEBLATE_ENABLE_HTTPS it doesn't make it use https, it just makes it assume that https reverse proxy is used in front of it. Probably the documentation should be clarified here...