XSRF errors on login with docker compose

[woodensquares]

I have installed espial via docker compose on my docker running box, however I cannot log in due to XSRF errors. This is my docker compose file (note the image name is a local copy of your image that I docker save / docker import here, as my docker box does not have access to the internet, but only to the local network, which is mynet2 here).

version: "2"

networks:
  macvlan:
    external:
      name: mynet2

services:
  espial:
    image: jonschoning/espial:espial
    restart: always
    networks:
      macvlan:
        ipv4_address: 172.22.10.92
    ports:
      - "80:80"
    volumes:
      - ./data:/app/data
    environment:
      - PORT=80
      - IP_FROM_HEADER=false
      - SQLITE_DATABASE=/app/data/espial.sqlite3

when I try to log in via a browser I get an XSRF error, which I also see in the docker log

(open the login page)
192.168.1.200 - - [17/Jan/2015:15:15:51 +0000] "GET / HTTP/1.1" 303 0 "" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"
192.168.1.200 - - [17/Jan/2015:15:15:51 +0000] "GET /auth/login HTTP/1.1" 200 - "" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"
192.168.1.200 - - [17/Jan/2015:15:15:51 +0000] "GET /static/css/tachyons.min.css?etag=jhoIzwsR HTTP/1.1" 304 - "http://172.22.10.92/auth/login" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"
192.168.1.200 - - [17/Jan/2015:15:15:51 +0000] "GET /static/css/main.css?etag=GyxCR4FW HTTP/1.1" 304 - "http://172.22.10.92/auth/login" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"

(submit the password)
17/Jan/2015:15:16:02 +0000 [Warn#yesod-core] A valid CSRF token wasn't present. Because the request could have been forged, it's been rejected altogether.
If you're a developer of this site, these tips will help you debug the issue:
- Read the Yesod.Core.Handler docs of the yesod-core package for details on CSRF protection.
- Check that your HTTP client is persisting cookies between requests, like a browser does.
- By default, the CSRF token is sent to the client in a cookie named XSRF-TOKEN.
- The server is looking for the token in the following locations:
  - An HTTP header named X-XSRF-TOKEN (which is not currently set)
  - A POST parameter named _token (which has the current, incorrect value: 'KcSEju61n5JQFkWjwAOBFwBos8qyC2OnBpgDbQIg') @(yesod-core-1.6.24.0-12q7eAY8cgKPjk7uY7MUx:Yesod.Core.Handler src/Yesod/Core/Handler.hs:1665:6)
192.168.1.200 - - [17/Jan/2015:15:16:02 +0000] "POST /auth/page/db/login HTTP/1.1" 403 - "http://172.22.10.92/auth/login" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"
192.168.1.200 - - [17/Jan/2015:15:16:02 +0000] "GET /static/css/tachyons.min.css?etag=jhoIzwsR HTTP/1.1" 304 - "http://172.22.10.92/auth/page/db/login" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"
192.168.1.200 - - [17/Jan/2015:15:16:02 +0000] "GET /static/css/main.css?etag=GyxCR4FW HTTP/1.1" 304 - "http://172.22.10.92/auth/page/db/login" "Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0"

I have tried this both with firefox and safari with identical results. Is something else I should be configuring? Is there any way to disable XSRF protection etc. (this is just in my local network which only I use, so I am not too worried about XSRF).

[jonschoning]

Can you verify that a _SESSION cookie is being sent in the browser login request?

it is sent along with the _token POST parameter, and looks somewhat like this:

_SESSION=QRM7uzQkrXD3nhW+ynw8RguXZW73j8ZZH950pKGgYkj/juLWPwgK9zPobrPHwt7Rtky1FGmFgkitBZZ/pZAN+VVC7qD3ZAHsvo0p0Np2BU76ZbFgklYz8VLKAZcNDoIBTJAEfGL+AdO3fgkDyZcPX634vpCmjdndF5xq2YmG53QV48pZszjUHxzrpmsQdxfzgX5TcHUShCTolmB9NQaYMZ8kEVsqTgJwCAAoCq+J;

It contains an encrypted form of the _token POST parameter; the two values must match

[woodensquares]

sorry for the delay, looking at the network inspector in firefox I do see the login page trying to set the cookie

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Date: Thu, 22 Jan 2015 15:22:38 GMT
Server: Warp/3.3.23
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Set-Cookie: _SESSION=CT7KFoh+4QIdSKXnJTxebMGbmLgctMTbrzsIMGpWD5YdY/RBR9YsmqqFBW1qrYzubUYMvFai70+ggQnX47oW3j2+afh5g5zvcbbmncxqiU7Yhub9NRsxWj2gvDKqaLwozVNfzxOOKPcgZ4AB4QkD8Br5lU5sW+RY9TBPx5iNrkHbCo9KH+A=; Path=/; Expires=Thu, 29-Jan-2015 15:22:38 GMT; HttpOnly
X-Frame-Options: DENY
Vary: Accept-Encoding, Accept, Accept-Language
X-XSS-Protection: 1; mode=block
Set-Cookie: XSRF-TOKEN=; path=/; expires=Thu, 01-Jan-1970 00:00:00 GMT
Set-Cookie: XSRF-TOKEN=xHi8qcTxlJMbXt4PijcmTVHWHqmTZBMFZbAtnXIk; Path=/

however when doing the login this is not sent

I only see an XSRF cookie sent, not a _SESSION cookie at all.

POST /auth/page/db/login HTTP/1.1
Host: espial.local
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 77
Origin: http://espial.local
Connection: keep-alive
Referer: http://espial.local/auth/login
Cookie: XSRF-TOKEN=xHi8qcTxlJMbXt4PijcmTVHWHqmTZBMFZbAtnXIk
Upgrade-Insecure-Requests: 1

could it be an issue that I only have espial in /etc/hosts (espial.local -> my local network docker container IP) and so HttpOnly cookies maybe are not working correctly?

[jonschoning]

The Expires value of the Session cookie sent by the server is set to 2015; you may want to try correcting the system time on the host first.

[woodensquares]

duh, good catch! I did not notice that, I forgot to update the clock last week when I had to shut down for a power outage. After setting the clock correctly everything works. Thanks!