Login fails with "Unknown error"

[figure002 (Serrano Pereira)]

Hello,

I’m running my own Discourse instance which I installed by following the basic Docker install guide. The issue I’m having is that after a few days of using the forum, login stops working entirely. Note that I’m the only user on this forum. But unfortunately I don’t know what’s causing the bug.

Steps to reproduce #1:

1. Install a new Discourse server by following instructions from Docker install guide.
2. Once the setup wizard has completed, verify you can successfully log out and back in.
3. Continue using the forum as normal. Just create some categories and posts. Maybe change the default theme.
4. After a few days or weeks of normal usage, you won’t be able to log back in after logging out. Login fails with “Unknown error” (displayed at the login form).

Steps to reproduce #2:

1. Install a new Discourse server by following instructions from Docker install guide.
2. Once the setup wizard has completed, verify you can successfully log out and back in.
3. Restore a backup from another Discourse instance where login was failing.
4. While the restore is in progress, you get a pop-up message saying that you were logged out. Restore was successful, but login fails with “Unknown error” (displayed at the login form).

I have tried debugging the issue myself, but I was unable to find any relevant error messages. This is what I’ve tried so far:

cd /var/discourse
./launcher enter app
tail -F log/production_errors.log
tail -F log/production.log
tail -F log/unicorn.stderr.log
tail -F log/unicorn.stdout.log

No error message appears in these logs during a failed login. What else can I do to help debug this problem? Thanks in advance.

[codinghorror (Jeff Atwood)]

Did you look at /logs in the web browser when logged in as admin?

[figure002 (Serrano Pereira)]

OK I figured something out. Login fails as soon as I enable the “force https” setting. My Discourse instance is behind a proxy server with SSL termination. As soon as I disable “force https”, login works again. So this is probably not a bug with Discourse, but rather an issue with my infrastructure setup.

I also did as you suggested, but there was no error message in the logs.

[figure002 (Serrano Pereira)]

Finally found the solution. The X-Forwarded-Proto header must be set, which is used for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.

Since I use HAProxy as my proxy server, I had to add this line to my HAProxy configuration:

http-request set-header X-Forwarded-Proto https if { ssl_fc }

Now login works fine even when “force https” is enabled.

[figure002 (Serrano Pereira)]

I also want to use the PROXY protocol over any connection established to my Discourse server. The PROXY protocol informs the other end (i.e. Discourse server) about the addresses of the incoming connection, so that it can know the client’s address or the public address it accessed to. Without this change, Nginx will not know the client’s address and all logs will contain the address of your reverse-proxy server instead. The following changes do the trick:

root@talk3:/var/discourse# git diff
diff --git a/templates/web.template.yml b/templates/web.template.yml
index a60e6ef..55cb5f2 100644
--- a/templates/web.template.yml
+++ b/templates/web.template.yml
@@ -116,6 +116,19 @@ run:
       to: daemon off;

   - replace:
+      filename: /etc/nginx/nginx.conf
+      from: /# server_tokens off;/
+      to: |
+        server_tokens off;
+        real_ip_header proxy_protocol;
+        set_real_ip_from 192.168.1.19;  # address of proxy server
+
+  - replace:
+      filename: "/etc/nginx/conf.d/discourse.conf"
+      from: /listen 80;$/
+      to: "listen 80 proxy_protocol;"
+
+  - replace:
       filename: "/etc/nginx/conf.d/discourse.conf"
       from: /upstream[^\}]+\}/m
       to: "upstream discourse {

And instruct HAProxy to enforce use of the PROXY protocol to this server:

-    server server-1 192.168.1.27:80 check
+    server server-1 192.168.1.27:80 check send-proxy

Finally do ./launcher rebuild app and verify it now logs the client addresses:

tail -F /var/discourse/shared/standalone/log/var-log/nginx/access.log