New install leaves me with session mismatch + invalid csrf

  • GNU/Linux

    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.

  • GNU/Linux

    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.

  • GNU/Linux

    @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 higher than 1.7.0 and that requires the path change that was in src/meta/js.js

  • GNU/Linux

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

             v6.9.1   (Latest LTS: Boron)
    [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 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: '',
      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:
    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:
    1/12 18:27 [12259] - info: [plugins/emoji-one] Emoji are ready.
    1/12 18:32 [12259] - error: /login
     invalid csrf token


  • GNU/Linux

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

    or direct local IP

  • GNU/Linux

    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):

  • GNU/Linux

    Seems like similar error which I've been experiencing lately (although I'm not using CentOs):

    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 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!

  • Community Rep

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

  • This is the value of url I was trying to use: "url": "".

  • Community Rep

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

  • @yariplus

    We're using Nginx. Here is the config

    upstream io_nodes {
    server {
      listen 80;
      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;
      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;";
  • Community Rep

    Are you running the server behind an AWS load balancer?

  • GNU/Linux Admin

    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.

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

  • GNU/Linux Admin

    @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?

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

  • GNU/Linux

    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.

  • GNU/Linux

    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

  • GNU/Linux Admin

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

Suggested Topics

| |