Login seems succesfull but does not actually logs user in.


  • I've setup NodeBB 1.2.1. on Ubuntu14.04 successfully and managed to register few users. Now I have an issue during login which says login has been succesfull and the app shows a welcome screen, but user actually does not seem to be logged in; it still shows Register and Login buttons at the top right of the screen. Would anyone have come across similar issue before or know how to solve it?


  • Check out ACP->Settings->Cookies

    "domain for session cookie"


  • @alff0x1f Thanks, what exactly should I set there? I cannot seem to able to login even to the ACP because of this issue.


  • @igor you must set your domain for cookie.
    For example ".community.nodebb.org" for this forum.


  • @alff0x1f I can't seem to be able to login into the APC as everytime when I try to, it seems to login, goes to the next screen but I'm not logged in. It says: "WELCOME BACK GUEST!
    You have successfully logged in". But I'm still shown Login and Register buttons.

  • Global Moderator Plugin & Theme Dev

    @igor have you tried disabling all plugins?

  • GNU/Linux Admin

    The common causes for a session mismatch error are usually one of the following:

    1. Mis-configured URL parameter in your config.json file

    If you have a misconfigured url value in your config.json file, the cookie may be saved incorrectly (or not at all), causing a session mismatch error. Please ensure that the link you are accessing your site with and the url defined match.

    2. Improper/malformed cookieDomain set in ACP

    Sometimes admins set this value without realising that they probably don't need to set it at all. The default is perfectly fine. This is what the config looks like:

    Cookie Domain setting

    If this is set, you'll want to revert the setting by editing your database directly:

    Redis: hdel config cookieDomain
    MongoDB: db.objects.update({ _key: "config" }, { $set: "cookieDomain": "" });

    3. Missing X-Forwarded-Proto header from nginx/apache

    If you are using a reverse proxy, you will need to have nginx pass a header through to NodeBB so it correctly determines the correct cookie secure property.

    In nginx, you will need to add the directive like so:

    location / {
        ...
        proxy_set_header X-Forwarded-Proto $scheme;
        ...
    }
    

  • For Apache:

    ProxyPassReverseCookiePath /nodebb /
    RequestHeader set X-Forwarded-Port "443"
    RequestHeader set X-Forwarded-Proto "https"
    

  • @julian said in Login seems succesfull but does not actually logs user in.:

    MongoDB: db.objects.update({ _key: "config" }, { $set: "cookieDomain": "" });

    1. With MongoDB server version: 4.4.6 I had to use this (note the additional curly braces for the argument to $set: {"cookieDomain": ""}:
    db.objects.update({ _key: "config" }, { $set: {"cookieDomain": ""} });
    WriteResult({ "nMatched" : 1, "nUpserted" : 0, "nModified" : 1 })
    
    1. config.json is correct, as configured.

    2. proxy_set_header X-Forwarded-Proto $scheme is set. As is proxying:

    listen 127.0.0.1:555 deferred proxy_protocol;
    set_real_ip_from  127.0.0.1;
    real_ip_header    proxy_protocol;
    proxy_set_header  X-Real-IP           $proxy_protocol_addr;
    proxy_set_header  X-Fowarded-For      $proxy_protocol_addr;
    proxy_set_header  X-Forwarded-Proto   https;
    proxy_set_header  Referer             $http_referer;
    proxy_set_header  Host                $host;
    proxy_headers_hash_max_size       768;
    proxy_headers_hash_bucket_size    128;
    

    Previously, login was dysfunctional already and changing X-Forwarded-Proto from $scheme to https seemed to fix it.

    Now it's malfunctioning again, despite the change (reverting does not change the behaviour). There may have been an nginx update meanwhile, though I doubt it's the reason. Somehow there's still something amiss I don't catch yet.

    Any ideas?

    Other things still bugging:

    • every X secconds the pop-up shows "Seems we lost connection to the server"
    • /manifest.webmanifest is a 401 though CORS crossorigin: use-credentials is set.
  • Global Moderator Plugin & Theme Dev

    @bejan your nginx config doesn't seem to match our recommended one:

            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://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";
    

    Note that these directives can be order sensitive.


  • @pitaj said in Login seems succesfull but does not actually logs user in.:

    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;

    Using this config does not solve the "login, welcome back as guest" issue.

    It does revert to the issue that the wrong client IP addresses are used in log files, though. This is why my config diverts from the recommended one. Bear in mind, I'm using ssl stream proxying here which requires a slightly different setup.

    Edit: Following the documentation you referenced I moved my proxy config inside the location / {} block and it is working now. I'll be da... Why isn't the location block inheriting the the server {}-wide block settings as one would expect? Do I need to provide the proxy settings inside the location /assets et al. blocks as well?

    To summarize: my config as specified above, used in a ssl-stream-proxy setup, provided inside the location / {} block seems to be working fine, login is working again as it should. It is however insufficient to globally specify those proxy settings in the server {} block (still ssl-stream-proxy setup).

    Thank you!


  • @pitaj

    Those other things still bugging are yet to be solved:

    1. every X secconds the pop-up shows "Seems we lost connection to the server"
    2. /manifest.webmanifest is a 401 though CORS crossorigin: use-credentials is set.

    -> about 1) Is this related to a ssl-stream-proxy setup?

  • Global Moderator Plugin & Theme Dev

    Do I need to provide the proxy settings inside the location /assets et al. blocks as well?

    No. See https://docs.nodebb.org/configuring/scaling/#use-a-proxy-server-to-serve-static-assets

    every X secconds the pop-up shows "Seems we lost connection to the server"

    Check out the following faq topic

    https://community.nodebb.org/topic/13388/faq-websockets-not-working-due-to-misconfigured-origins

    /manifest.webmanifest is a 401 though CORS crossorigin: use-credentials is set.

    Not sure. Can you show a screenshot of this happening? Can you try clearing your cookies and cache? What browser?

Suggested Topics

  • 1
  • 4
  • 2
  • 2
  • 3
| |