I get Forbidden on login. "Invalid csrf token" shows in the server logs. I upgraded from 0.7.0 to 0.7.1 and started having the problem. I am using mongodb.
On POST to /login, the x-csrf-token is set to the same thing that was passed in the GET response of /login. I tried reinstalling all node modules. I also cleared all sessions from the sessions collection in mongodb. No new sessions are being created due to not being able to get pass CSRF validation. I also tried changing the secret in config.json.
EDIT: Apparently, there is something in the database that affects CSRF. I installed a seperate version of nodebb with new files and database. Logging in worked. I switched (config.json) to the old database and it was Forbidden again.
Other settings:
From config.json:
"url": "http://community.bushwookies.com",
From nginx vhost:
server {
listen 80;
#listen [::]:80;
server_name community.bushwookies.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;
# Socket.IO Support
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
}
}
Other settings:
From config.json:
"url": "http://community.bushwookies.com",
shoudn't that have :4567 port on the end
Hm.. that's very weird that the same code but different database would cause CSRF errors.
We're acutely aware that people are experiencing them, but we're at a loss to debug because we personally cannot reproduce them.
As far as I know, the CSRF tokens have nothing to do with the database contents... are you on Redis or Mongo?
Perhaps deleting all of the sess:* keys is worth a shot...
I am using Mongo. I will look for any sess keys. I will also try to copy a few settings at a time over to the new installation to see if I can break it in the same way.
Well, it was something foolish I changed that caused this. "Days to remember user login sessions" was set to 0. This seemed to work at first, but it actually prevents you from logging in.
After the CSRF error was cleared up, I wanted to see if this was definitely what broke it. Yet, setting it to 0 again appeared to have different behavior. It just brings you back to the homepage as a guest after you try to login instead of failing with any errors such as Forbidden (due to CSRF).
Actually, it seemed like the CSRF problem was not immediately resolved after increasing the days setting, but I didn't do much else, except to copy all data including accounts to the new installation so that I could log in as my usual user.
I actually copied the entire objects collection and ran ./nodebb setup to recreate the other collections. This allowed me to log into my usual account successfully on the new installation. Somehow, after this, logging in was working on the old installation without changing anything in the original database. This doesn't make sense though, so it must have just been that one setting causing all the problems.
But you are not getting the csrf error if you set the value back to 0?
No, I can't seem to replicate the CSRF error state, which lasted a couple of days. If I set it to 0 now, I just get redirected to homepage with no login errors but as guest (logged out).
It seems that some users had to clear cookies (and maybe html5 localstorage) to get pass the Forbidden error, even after it was fixed for me. When I was having the problem initially, clearing cookies didn't seem to help, but at least one form of the error is due to having outdated cookies. This may have been caused by changing the secret key in config.json.
