Login seems succesfull but does not actually logs user in.

[PitaJ]

@igor have you tried disabling all plugins?

[julian]

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:

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;
    ...
}

[Keng Her]

For Apache:

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

[Bejan]

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

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

2. 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.

[PitaJ]

@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.
https://docs.nodebb.org/configuring/proxies/nginx/

[Bejan]

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

[Bejan]

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

[PitaJ]

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

[FAQ] Websockets not working due to misconfigured origins

This FAQ is applicable for the following situations: You're receiving the following error in the Javascript console: WebSocket connection to 'wss:///socket...

NodeBB Community (community.nodebb.org)

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

[Bejan]

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

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

Check out the following faq topic

[FAQ] Websockets not working due to misconfigured origins

This FAQ is applicable for the following situations: You're receiving the following error in the Javascript console: WebSocket connection to 'wss:///socket...

NodeBB Community (community.nodebb.org)

I only have a single origin site and the url is set as it should. Is it allowed to have a trailing slash in url?

This issue is still haunting me.

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

The manifest issue is solved. Thank you.

[PitaJ]

@bejan try removing the trailing slash but that's probably not it.

I'd suggest reducing your nginx config down to the bare minimum as recommended in the docs and perhaps even try it with direct http to see if you still see that error.

[Bejan]

@pitaj Yeah, that's what it most probably boils down to. Right now, it's not a priority. Yet.

Will let you guys know when it's done and how.

So far: thank you for your support and patience. You guys rock. Docs aren't too recent and complete but you make it up. Of course it takes your time and mine to solve those issues that might not even surface with more extensive documentation. What I mean is, the available doc is already very nice. It's the little crooks and crannies and the code version referenced that could profit from some polish. As already offered, I can offer to improve on that if wanted. I.e. just add what was missing for me that would complement the doc that is there. Just my 2p

[gotwf]

@bejan The nodebb recommended nginx.conf works dandy. Should you want/need more w.r.t. nginx security related concepts, I recommend raymii.org:

Strong SSL Security on nginx

There are a number of relevant articles there relating to various web server security knobs and tweaks. Apache included.

Have fun down the rabbit hole!

[Bejan]

@gotwf I appreciate your reply, thank you.

Not everyone can use the standard setup or just may not want to implement it this way.

In my case I have a particular situation where the standard config is only a part of the bigger picture. To reach a working setup with all dependencies fullfilled, I had to tweak it quite a bit. In the end, some directives of the nodebb config weren't as suggested by the docs. To really know what can be done different and what not for nodebb to still work flawlessly is harder for anyone just starting with nodebb. It needs a helping hand to get it working again and now it's finally ready. So far I'm happy with how it is as of now.

The remaining issue is nothing major requiring immediate remedy right now.

[julian]

@bejan Our community reps are pretty awesome, we're lucky to have them

Our docs are open source, and we accept pull requests to them: https://github.com/nodebb/docs

We would greatly appreciate tweaks to the docs so that they are more accessible.

While I suppose more documentation doesn't always mean better documentation, we are always grateful for contributions

[Bejan]

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

@bejan Our community reps are pretty awesome,

Definitely!

Our docs are open source, and we accept pull requests to them: https://github.com/nodebb/docs

Great, thank you!

While I suppose more documentation doesn't always mean better documentation, we are always grateful for contributions

True