Invalid cookie when using reverse proxy

My version of HedgeDoc is: 1.9.9

I have a fresh deployment of HedgeDoc to test the latest version 1.9.9 and also to try it with high-availability (HA) PostgreSQL*. The Helm chart I am using to deploy this instance is here for reference. (What is not obvious from those template files is that the TLS certs and termination are handled by a Traefik ingress controller I run independently of the HedgeDoc deployment.)

*Unfortunately I see in the FAQ that the HedgeDoc server itself does not support HA.

What I expected to happen:

HedgeDoc editor to load correctly in a browser (Firefox on Ubuntu).

What actually happened:

The editor displays an endless spinner. The browser console shows that all requests are succeeding (code 200) and the only JS console error (aside from the Content-Security-Policy errors about inline scripts that I also see on my functioning HedgeDoc instance so I ignore them) is about an invalid cookie:

AUTH failed: Cookie is invalid.

The NGINX reverse proxy configuration (shown below) must be the cause of the problem, because when I use the root domain (e.g. example.com) instead of a base path (e.g. example.com/docs), in which case my Helm chart does not deploy the NGINX reverse proxy components, then HedgeDoc works correctly.

map $http_upgrade $connection_upgrade {
      default upgrade;
      ''      close;
}
server {
  listen       80;
  listen  [::]:80;
  server_name  {{ .Values.ingress.hostname }};
  
  location /{{ .Values.ingress.basepath }}/ {
    proxy_set_header        Host $host;
    proxy_set_header        X-Real-IP $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header        X-Forwarded-Proto $scheme;

    proxy_pass              http://{{ .Release.Name }}-server:80/;

    proxy_read_timeout      600s;
    proxy_send_timeout      600s;
  }
  location /{{ .Values.ingress.basepath }}/socket.io/ {
    proxy_set_header        Host $host; 
    proxy_set_header        X-Real-IP $remote_addr; 
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for; 
    proxy_set_header        X-Forwarded-Proto $scheme;
    proxy_set_header        Upgrade $http_upgrade;
    proxy_set_header        Connection $connection_upgrade;

    proxy_pass              http://{{ .Release.Name }}-server:80/socket.io/;
  }
}

Hi @manning-ncsa,

the AUTH failed message is tied to problems with the same-origin cookie policy.

Important for HedgeDoc is to know whether it is served via HTTP or HTTPS. This is indicated by the config option protocolUseSSL (or the corresponding environment variable). Otherwise the Cookies will be set for a different origin (same domain but different protocol is treated as another origin) and HedgeDoc can’t access them.

I just took a quick look at the helm chart and while I didn’t analyze it thoroughly, it seems there are some problems with the config.yaml template.
Especially in line 9 the config option protocolUseSSL is set to the value of cookiePolicy which does not make any sense and looks like a copy-and-paste error from the line above.
Be careful as there are more such wrong assignments in the file.

If fixing this doesn’t help fix your issue, it might be that the subpath deployment makes some problems. Be sure to have the urlPath config option correctly set. However, we’re encouraging users to avoid subpath deployments if possible as they sometimes produce hard-to-reproduce issues. The upcoming version 2.0 won’t have the option for subpath deployments anymore.

Best regards,
Erik

Thanks for catching that! Wow, copy and paste really messed me up here. With fresh eyes I also see that on line 7 I have useSSL set to the logLevel value (and also an oauth config reference mistake) :person_facepalming:

I had forgotten about this but now recall reading it in another post months ago. This means I should drop the complexity of the reverse proxy option I guess. Thanks for the reminder.