Session Mismatch

[Adam Poniatowski]

I am having the same issue. I am running it on FreeBSD

[julian]

Hello to you both,

The common causes for a session mismatch error are usually one of the following:

1. Mis-configured URL parameter in your config.json file

If you have a misconfigured url value in your config.json file, the cookie may be saved incorrectly (or not at all), causing a session mismatch error. Please ensure that the link you are accessing your site with and the url defined match.

2. Improper/malformed cookieDomain set in ACP

Sometimes admins set this value without realising that they probably don't need to set it at all. The default is perfectly fine. This is what the config looks like:

If this is set, you'll want to revert the setting by editing your database directly:

Redis: hdel config cookieDomain
MongoDB: db.objects.update({ _key: "config" }, { $set: "cookieDomain": "" });

3. Missing X-Forwarded-Proto header from nginx/apache

If you are using a reverse proxy, you will need to have nginx pass a header through to NodeBB so it correctly determines the correct cookie secure property.

In nginx, you will need to add the directive like so:

location / {
    ...
    proxy_set_header X-Forwarded-Proto $scheme;
    ...
}

[Adam Poniatowski]

I'm getting an error...

SyntaxError: Unexpected token :

[Adam Poniatowski]

I forgot to mention, this is on mongo. I don't know how to correct the syntax.

[baris]

db.objects.update({ _key: "config" }, { $set: "cookieDomain": "" });

Should be

db.objects.update({ _key: "config" }, { $set: {"cookieDomain": "" }});

[Adam Poniatowski]

that worked... but not sure if it really did anything:

WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 0 })

If I read that correctly, it found the entry, but it did not update anything?

[Adam Poniatowski]

Thank you, that resolved the issue.

*Edit to add:

When I tried to log in, it gave me an error that it could not find the following page:
http://localhost:4567/?loggedin

Which is understandable... my firewall is blocking that port and my reverse proxy (nginx) is serving this. But why does this happen? When I press back, it takes me to the actual page, but a lot of "session mismatch" errors pop up. And when I log out and try to log back in, then I have the same issue? I am doing this from work, but at home, I don't have this issue.

**Edit to add again:
I tried again, the session mismatch is not there, but the same issue reoccured.

"This site can’t be reached

localhost refused to connect.
Search Google for localhost 4567"

This used to work, before I updated nodebb, so it can't be a nginx issue.

When I go back to my page (again) and log in, now it is fine. I will try logging out and back in again.

***Edit:

Nope... session mismatch again, up until I close the browser and try again. So this is a endless loop of session mismatches.

[Adam Poniatowski]

Resolved it by using my domain name in config.json (minus :4567)

[Shaun]

@julian I'm getting this error. The forums work for people who were logged in before I upgraded (went from 1.0.3 to 1.2.1) but no one who wasn't logged in can do so and no new users can register. And as far as I can tell, I can't even temporarily disable the CSRF token as a work-around, which is pretty frustrating.

1. CONFIG.JSON URL value is correct, but involves a subdomain installation (/forums) and an HTTPS URL.

2. COOKIEDOMAIN was already blank, but I ran the redis script to clear it anyway.

3. This value was not present (because it was not in the original NGINX configuration document), but I added it and nothing changed. The NGINX config I use is given below. It's probably important to note that I use SSL for all incoming connections, and the URL value from my config.json includes https:// at the beginning. NGINX and NodeBB are run on the same server, so SSL is not used between them.

   location /forums {
           client_max_body_size 20M;
           proxy_set_header X-Real-IP $remote_addr;
           proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
           proxy_set_header Host $http_host;
           proxy_set_header X-NginX-Proxy true;
           proxy_set_header X-Forwarded-Proto $scheme;
   
           proxy_pass http://127.0.0.1:4567/forums;
           proxy_redirect off;
   
           # Socket.IO Support
           proxy_http_version 1.1;
           proxy_set_header Upgrade $http_upgrade;
           proxy_set_header Connection "upgrade";
   }
   

[julian]

Not sure if you need /forums defined in both the location block and the proxy pass block...

[Shaun]

@julian it was required to make this configuration work back in 1.0.x. Is there one or another of the two you would recommend removing? My only other option at this point seems to be to revert to the VM snapshot I made of 1.0.3, but that's going to mean losing about a week's worth of new posts, since I didn't notice this was broken after the upgrade.

[PitaJ]

@Shaun can you post your config.json? Remove your passwords etc. Just want to make absolutely sure.

[Shaun]

@PitaJ I will grab the whole thing for you, tomorrow, if I remember, but the "url" value is "https://www.example.com/forums" and I think that's the only value that should have an impact, here.

[Shaun]

@PitaJ

{
    "url": "https://www.example.net/forums",
    "secret": "88888888-8888-8888-8888-888888888888",
    "database": "redis",
    "port": 4567,
    "redis": {
        "host": "127.0.0.1",
        "port": "6379",
        "database": "0"
    }
}

[Shaun]

@julian Also ... the location block is because I serve the URL from /forums on the reverse proxy. It is included in the proxy pass because NodeBB is also configured to respond to /forums (so, accessing it by the IP and Port directly from my network also requires appending "/forums"). I found that it must be set that way for various resource paths (CSS and script files, I think) to get served correctly.

[julian]

Sounds about right, but I recall vaguely that setting it in the proxy pass block means that NodeBB itself receives the request without /forum... sort of like nginx captures it and removes it from the url as it proxies it.

Just something to think about, not sure if it applies here, but it would explain why the session mismatch is occurring.

Perhaps back up the nginx config and play around with the various configurations until you hit upon one that works?

[Shaun]

@julian said in Session Mismatch:

sort of like nginx captures it and removes it from the url as it proxies it.

That can't be the case, because NodeBB doesn't respond without the /forums. For example, if I put the IP and port into my address bar (http://192.168.0.10:4567/), I get a connection refused error, but http://192.168.0.10:4567/forums responds. Edit: This isn't to say that the sub-folder installation couldn't be the cause of the problem - just that NginX seems to be passing the URL correctly.

I'm kind of wondering if this has something to do with SSL.

[EnDylan]

@julian
Ok. Thanks.