Login failing, "likely due to an expired session."
-
OK, clearing browser site data causes the login error dialog to go away, but I get a page that just says 'forbidden' instead.
I tried running ./nodebb dev and the log ends with: "invalid csrf token" so I suspect it's really the same problem.
Pretty much out of ideas at this point...
-
@marksibly potentially a long shot, but try this
Invalid CSRF on dev install
I wanted to create a DEV instance of sudonix, so went ahead and registered sudonix.dev, installed NodeBB, then recovered the database. All good - apart from ...
Sudonix | A one-stop-shop for all your technology questions (sudonix.org)
-
@marksibly potentially a long shot, but try this
Thanks, but adding cookieDomain to the DB config didn't seem to do anything.
One weird thing suggested in that thread does appear to mostly work though, ie: using http:// instead of https:// in the config url, even though my site is definitely an https site. Even localhost:// 'works'...anything as long as it's wrong apparently!
Only mostly though, because absolute URLs in the nodebb pages fail with 'Blocked loading mixed active content', I assume because the browser ends up trying to load http from an https page?
But most URLs in nodebb pages are domain relative, eg: "/forum/login" etc so the site pretty much works - it's missing an emoji or too I think. You can at least log in and out which is a massive improvement!
I may or may not consider 'patching' the proxy responses, eg: replacing "http://skirmish-dev.net/" with "https://skirmish-dev.net" etc, which sounds like a hot mess solution but I can't think what else to do.
Bye,
Mark -
OK, I've finally found a solution that seems to fix all the problems I've been having!
Nodebb has an nconf setting called 'secure' that is true for https urls, false otherwise. This only seems to be used by cookie related code.
But in my case at least, setting this to true was causing cookies to somehow fail, so I simply forced it to false regardless of url and viola, I could use my real https url without any problems.
You can do this easily by modifying src/prestart.js (approx line 100), eg:
// nconf.set('secure', urlObject.protocol === 'https:'); nconf.set('secure', false);
This fixes the problem in both v2.x and v3.6.5 branches.
Not sure if this means there's a bug somewhere, perhaps my cookieDomain is incorrect although I can find no docs on what it should be set to.
A nice bonus is that this has allowed me to reduce my proxying code to one line:
app.use("/forum", createProxyMiddleware({target: "http://localhost:4567"}));
(Using the http-proxy-middleware module).
Bye,
Mark -
Using node as a proxy like this isn't recommended. We should probably remove it from the docs.
-
I think I've found the silver bullet here: you need to set the 'xfwd' option when creating the proxy. With this option enabled, I no longer have to hack the cookie secure flag as above and everything (v.3.6.5) appears to be working perfectly. I'm using http-proxy-middleware, but it should work with any http proxy AFAICT as 'xfwd' is actually part of the base http-proxy module which everything else seems to be built upon.
So to proxy using the http-proxy module:
const proxy = httpProxy.createProxyServer(); app.use("/forum", (req, res) => { proxy.web(req, res, {target:"http://localhost:4567/forum", xfwd: true}); });
...and to proxy using the http-proxy-middleware module:
app.use("/forum", createProxyMiddleware({target: "http://localhost:4567", xfwd: true}));
Bye!
Mark -
@marksibly
I encountered the same issue. InternalLinkSorted it by adding
proxy_set_header X-Forwarded-Proto $scheme;
in thenginx
conf file -
Sorted it by adding proxy_set_header X-Forwarded-Proto $scheme; in the nginx conf file
Problem is, I'm just using 'raw' node.js, so there is no nginx (or apache etc) conf file.
But your above post did inspire me to find out what the equivalent was for node proxys so thanks!
Bye,
Mark -
Check config.json
Unset cookieDomain
Set x-forwarded-protoYep, agreed, that would cover all the problems I encountered I think.
IMO, the node.js proxy docs need to be updated. At the very least, they need to mention the {xfwd: true} option, but they could also be streamlined to a much simpler example as above.
Bye,
Mark -
@marksibly thank you for the comments, you're right, they can be updated.
The problem is I am not familiar with it enough as I am more familiar with nginx and will always reach for it.
Are you able to make the appropriate changes in our docs?
GitHub - NodeBB/docs: NodeBB Documentation via MkDocs
NodeBB Documentation via MkDocs. Contribute to NodeBB/docs development by creating an account on GitHub.
GitHub (github.com)
-
Are you able to make the appropriate changes in our docs?
Yes, can do, I should have something ready to go soon-ish.
[edit]
https://github.com/NodeBB/docs/pull/89
[/edit]