New install leaves me with session mismatch + invalid csrf
-
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
-
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
-
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
-
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?
-
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!
-
What are you using for your url in
config.json
? -
This is the value of url I was trying to use: "url": "https://forums.coinfetch.com".
-
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;"; }
-
Are you running the server behind an AWS load balancer?
-
@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? -
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.
-
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
-
@JaredBusch That's a new requirement -- surprised we didn't catch that it was missing in your config earlier
-
@JaredBusch said in New install leaves me with session mismatch + invalid csrf:
proxy_set_header X-Forwarded-Proto $scheme;
server { listen 80; server_name www.docfindy.com; location / { 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_pass http://127.0.0.1:4567/; proxy_redirect off; proxy_set_header X-Forwarded-Proto $scheme; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } server { listen 80; server_name docfindy.com; return 301 http://www.docfindy.com$request_uri; }
I am using Mongo 3.2 and Nodebb 1.4.2, this is my nginx config file, session mismatch still present, plaase help.
@JaredBusch @julian -
@Pramvir-Rathee here is my current Nginx config for the site.
server { client_max_body_size 40M; listen 443 ssl; server_name community.bundystl.com; ssl on; ssl_certificate /etc/letsencrypt/live/bundystl.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/bundystl.com/privkey.pem; ssl_stapling on; ssl_stapling_verify on; ssl_protocols TLSv1.2 TLSv1.1 TLSv1; ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; ssl_prefer_server_ciphers on; ssl_session_cache shared:SSL:10m; ssl_dhparam /etc/ssl/certs/dhparam.pem; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; location / { 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 Host $http_host; proxy_set_header X-NginX-Proxy true; proxy_pass http://10.254.0.35:4567; proxy_redirect off; # Socket.IO Support proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; } } server { client_max_body_size 40M; listen 80; server_name community.bundystl.com; rewrite ^ https://$server_name$request_uri? permanent; }