New install leaves me with session mismatch + invalid csrf

JaredBusch

Installed v6.9.1 with 1.3.0 and it all worked once I modified src/meta/js.js to have the new path.

Deleted the nodebb folder and dropped the database.

installed 7.2.0 along side 6.9.1 via nvm install v7.2.0
0_1480626320682_upload-33a780a8-e2ce-4031-9dae-79f4bf646301

cloned master

ran setup

it all works this time.

JaredBusch

I spoke too soon.

I logged out of the site to try and make a new account and immediately received the session mismatch error.

Then when I tried to log back in with the admin account I received a csrf token error.

JaredBusch

@teh_g said in New install leaves me with session mismatch + invalid csrf:

@JaredBusch Yup, that is what I am using:

a new install using node 6.9.1 still sets up socket.io-client higher than 1.7.0 and that requires the path change that was in src/meta/js.js

JaredBusch

Brand new VM (and this time I made a snapshot prior to installing NPM)

         v6.9.1   (Latest LTS: Boron)
         v7.0.0
         v7.1.0
         v7.2.0
[root@bna-cmty ~]# nvm install v6.9.1
######################################################################## 100.0%
Computing checksum with sha256sum
Checksums matched!
Now using node v6.9.1 (npm v3.10.8)
Creating default alias: default -> v6.9.1
[root@bna-cmty ~]# cd /opt
[root@bna-cmty opt]# git clone -b v1.x.x https://github.com/NodeBB/NodeBB nodebb
Cloning into 'nodebb'...
remote: Counting objects: 113047, done.
remote: Compressing objects: 100% (237/237), done.
remote: Total 113047 (delta 141), reused 2 (delta 2), pack-reused 112806
Receiving objects: 100% (113047/113047), 34.95 MiB | 10.35 MiB/s, done.
Resolving deltas: 100% (84842/84842), done.
[root@bna-cmty opt]# cd nodebb
[root@bna-cmty nodebb]# git branch
* v1.x.x

[root@bna-cmty nodebb]# npm version
{ nodebb: '1.4.0',
  npm: '3.10.8',
  ares: '1.10.1-DEV',
  http_parser: '2.7.0',
  icu: '57.1',
  modules: '48',
  node: '6.9.1',
  openssl: '1.0.2j',
  uv: '1.9.1',
  v8: '5.1.281.84',
  zlib: '1.2.8' }
[root@bna-cmty nodebb]#

[root@bna-cmty nodebb]# ./nodebb log

Hit Ctrl-C to exit

tail: cannot open ‘./logs/output.log’ for reading: No such file or directory
tail: ‘./logs/output.log’ has appeared;  following end of new file

NodeBB v1.4.0 Copyright (C) 2013-2014 NodeBB Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it under certain conditions.
For the full license, please visit: http://www.gnu.org/copyleft/gpl.html

Clustering enabled: Spinning up 1 process(es).

1/12 18:27 [12259] - info: Time: Thu Dec 01 2016 18:27:14 GMT-0600 (CST)
1/12 18:27 [12259] - info: Initializing NodeBB v1.4.0
1/12 18:27 [12259] - info: [database] Checking database indices.
1/12 18:27 [12259] - info: [database] Checking database indices done!
1/12 18:27 [12259] - info: initializing NodeBB ...
1/12 18:27 [12259] - info: [plugins/emoji-one] Initial startup detected. Downloading emojione assets...
1/12 18:27 [12259] - info: Routes added
1/12 18:27 [12259] - info: NodeBB Ready
1/12 18:27 [12259] - info: Enabling 'trust proxy'
1/12 18:27 [12259] - info: NodeBB is now listening on: 0.0.0.0:4567
1/12 18:27 [12259] - info: [plugins/emoji-one] Emoji are ready.
1/12 18:32 [12259] - error: /login
 invalid csrf token

0_1480638890529_upload-9904b93e-683e-4621-9f90-696922234ae0

JaredBusch

I get these errors either through the Nginx proxy I have in front of it (on another VM)

or direct local IP http://10.254.0.35:4567
0_1480639368627_upload-ffbed6f6-20ae-4836-9469-84aa061072a1

JaredBusch

New VM and used Node 4.6.2 and NodeBB 1.x.x (which now pulls 1.4.0)

Same problems.

There has to be something else causing the problem.

So any ideas on where I can look to track it down.

Again, I followed these instructions (that I wrote based on the official docs): https://mangolassi.it/topic/11695/installing-nodebb-with-mongo-on-centos-7

metalkramp

Seems like similar error which I've been experiencing lately (although I'm not using CentOs): https://community.nodebb.org/topic/9886/invalid-csrf-token/3

Perhaps we can figure it out together. Have you tried using older version like 1.1.2?

tin

I am seeing the same issue here. I have tried 1.4.0 with both Node 7.2.1 and 6.9.2 on a Ubuntu VM with Redis.

The problem seems to be with the url. NodeBB does not seem to like https://domain.com url. It worked fine when I reverted back to the default http://localhost:4567 but using the localhost URL means assets required by plugins such as emoji are not serving correctly.

This seems to be a pretty critical bug. Any way to prioritize a fix for it?

Thank you!

yariplus

What are you using for your url in config.json?

tin

This is the value of url I was trying to use: "url": "https://forums.coinfetch.com".

yariplus

@tin Are you using nginx or apache? Can you post your config.

tin

@yariplus

We're using Nginx. Here is the config

upstream io_nodes {
  ip_hash;
  server 127.0.0.1:4567;
  server 127.0.0.1:4568;
  server 127.0.0.1:4569;
  server 127.0.0.1:4570;
}

server {
  listen 80;
  server_name forums.coinfetch.com;
  charset utf-8;

  location /health_check {
    proxy_next_upstream error;
    proxy_redirect off;
    proxy_set_header Host $http_host;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_pass http://io_nodes;
    break;
  }

  proxy_next_upstream error;
  proxy_redirect off;
  proxy_set_header Host $http_host; 
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  proxy_set_header X-Forwarded-Proto $scheme;
  proxy_set_header X-NginX-Proxy true;
  proxy_set_header X-Real-IP $remote_addr;
  if ($http_x_forwarded_proto != "https") {
    return 301 https://$host$request_uri;
  }
  
  # Socket.IO Support
  proxy_http_version 1.1;
  proxy_set_header Connection "upgrade";
  proxy_set_header Upgrade $http_upgrade;
  
  gzip on;
  gzip_comp_level 5;
  gzip_min_length 1000;
  gzip_proxied any;
  gzip_types *;

  location @nodebb {
    proxy_pass http://io_nodes;
  }

  location ~ ^/(images|language|sounds|templates|uploads|vendor|src\/modules|nodebb\.min\.js|stylesheet\.css|admin\.css) {
    root /var/www/coinfetchbb/;
    try_files $uri $uri/ @nodebb;
  }

  location / {
    proxy_pass http://io_nodes;
  }    

  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains;";
}

yariplus

Are you running the server behind an AWS load balancer?

julian

Your nginx config suggests it is listening on port 80, whereas your config is set up with https... that will cause a session mismatch error.

tin

@julian @yariplus - yes, we are running behind a load balancer listening to https. Is that an issue?

julian

@tin If your load balancer terminates SSL and proxies the connection to nginx (and NodeBB) as http, then nginx is telling NodeBB that the protocol is HTTP when it should be HTTPS.

proxy_set_header X-Forwarded-Proto $scheme;

Change this to https and try again?

tin

@julian, that did the trick. Thank you so much!

JaredBusch

I have never gotten this new install to work. It is extremely frustrating.

I have an older install, that is on 1.2 or 1.3, that I upgrade to 1.4.0 and it started having the same problems, so I reverted to the snapshot I had made of that VM prior to upgrading.

I am going to delete the new VM and start over one more time.

JaredBusch

So I have the site working. I did not have this line in my Nginx config. My Nginx is on a different host, not the same one.

proxy_set_header X-Forwarded-Proto $scheme;

But I have never had it and the previous existing sites have worked.

It also does not explain why I received the error on the existing install after an upgrade from 1.3.0 to 1.4.0

julian

@JaredBusch That's a new requirement -- surprised we didn't catch that it was missing in your config earlier