New install leaves me with session mismatch + invalid csrf
-
Nuked the install and used v1.2.0 and the Session mismatch is gone, but the csrf is still around.
I changed the socket.io version as mentioned in this https://github.com/NodeBB/NodeBB/issues/5241
and session error came back.
So this leads me to believe it is an issues with the versions of something installed.
Is there some level of Node that I should revert back to as a whole instead of using 7.2.0?
[root@bna-cmty nodebb]# npm version { nodebb: '1.2.0', npm: '3.10.9', ares: '1.10.1-DEV', cldr: '30.0.2', http_parser: '2.7.0', icu: '58.1', modules: '51', node: '7.2.0', openssl: '1.0.2j', tz: '2016g', unicode: '9.0', uv: '1.10.1', v8: '5.4.500.43', zlib: '1.2.8' } [root@bna-cmty nodebb]#
-
@teh_g said in New install leaves me with session mismatch + invalid csrf:
Anecdotally, I have no issues with the LTS release of node.
6.9.1?
-
@JaredBusch Yup, that is what I am using:
-
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
cloned master
ran setup
it all works this time.
-
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.
-
@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
-
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?