csrf invalid - socket.io

Solved Technical Support
  • I just installed my forum with nodebb and even though my site loads it won't let me log in. The errors I get are as follows:

    alt text
    alt text

    config.json

    {
        "url": "[URL-SITE]",
        "secret": "[SECRET]",
        "database": "mongo",
        "mongo": {
            "host": "127.0.0.1",
            "port": 27017,
            "username": "[DB USER]",
            "password": "[DB PASSWORD]",
            "database": "nodebb",
            "uri": "mongodb://[DB USER]:[DB PASSWORD]@127.0.0.1:27017/nodebb"
        }
    }
    
  • Make sure that url in config.json matches the address you're using to access NodeBB.

  • @julian The url matches me, I don't know what the error is...

  • In case it's any information, I'm using CloudFlare as a DNS manager.

  • Can you paste your reverse proxy settings? Nginx etc?

  • In the end I solved it by removing Cloudflare as DNS manager, I tried many ways I saw on the forum to try to make it work with Cloudflare but it was impossible.

  • M Meketeke has marked this topic as solved on
  • @Meketeke Removing CF as DNS manager would have zero effect on NodeBB. However, the other components have some "interesting" effects (none positive, including Google Search) which is why I removed all aspects of it apart from DNS.

  • Getting this same issue on local testing box. Fresh install of nodeBB v3.4.2's ./nodebb log says:

    2023-09-15T00:55:23.673Z [50009/3928] - error: POST /login
    invalid csrf token
    

    Web browser console says says:

    https://test7.dev.cc/socket.io/?_csrf=6a4d4c...43eb&EIO=4&transport=polling&t=OgMM4ww
    Failed to load resource: the server responded with a status of 403 ()
    

    config.json is pretty straightforward, granted I'm using PostgreSQL which isn't really well documented here. Had success with nodeBB 2.X, 3.X supported?

    {
        "url": "https://test7.dev.cc",
        "port": "50009",
        "bind_address": "127.0.0.1",
        "secret": "579e7ab9f9b57859734b15638a485e31",
        "database": "postgres",
        "postgres": {
            "host": "127.0.0.1",
            "port": "5432",
            "username": "pws_nodebb",
            "password": "NBpass123",
            "database": "pws_nodebb",
            "ssl": "false"
        }
    }
    

    Nginx configuration is pretty straight forward. Works with ExpressJS, and websocket-y apps (NodeRED, etc.) without issue:

    location / {
                        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                        proxy_set_header Host $host;
                        proxy_pass http://127.0.0.1:$nodebb_port;
                        proxy_http_version 1.1;
                        proxy_set_header Upgrade $http_upgrade;
                        proxy_set_header Connection "upgrade";
                    }
    

    Not really sure what to make of it other than the subfolder /socket.io/ seems kinda interesting; is it attempting to establish a websocket with a subfolder URL definition? Not sure if that elicits further location definitions in Nginx.

    Any suggestions greatly appreciated.

  • Update: I found the issue, the Nginx configuration for proxy_set_header X-Forwarded-Proto $scheme; needed to be added to the definition.

  • @Steveorevo wow! You must've had a very old version of NodeBB!

  • @Meketeke I think removing Cloudflare as proxy or DNS manager was not the solution as it defied the whole reason and purpose you tried to use Cf in the first place (which are the anti DDoS and other stuff). The solution was quite simple as @julian pointed out, the url in the config.json should match the setting in whatever reverse proxy you are using on the machine (say it NginX). If you are like me who is not using https in NginX since Cloudflare already does that, then the url in your config.json should be something like http://yourdomain.com, instead of https://yourdomain.com as one may first suppose.

    At least that's how I solved the very same problem yesterday.

  • To be honest NodeBB shouldn't require the reverse proxy to pass the protocol in, I will have to take a closer look as to why that is needed.


Suggested Topics