CSRF error when logging in after URL change

[Moritz Friedrich]

I experienced several CSRF errors before, mostly due to cookie/cache issues or dated themes.
Now this time, I changed the domain from test.domain.com to domain.com in my nginx config file and the nodeBB config.json. After that, I restarted nginx and NodeBB and tried to login, but am unable to because I'm getting "Forbidden" in the browser and error: /login - Invalid CSRF token in the logfile.

Neither git pulling, npm uping, deleting the browser cache, restarting NodeBB/nginx/redis/the whole machine or using a completely different machine in another network helps.

Any ideas?

config.json:

{
    "url": "https://schreibnacht.de",
    "port": ["4567", "4568", "4569"],
    "secret": " ... ",
    "database": "redis",
    "redis": {
        "host": "127.0.0.1",
        "port": "6379",
        "password": " ... ",
        "database": "0"
    }

EDIT: Weird enough, I just realized that at the old subdomain (as a CNAME) logging in is still possible...

[nhl.pl]

Try to update/reinstall theme or install new one for test purposes.

As I can see it could be anything from email address in datastore to page title:
https://github.com/NodeBB/NodeBB/issues/2571#issuecomment-68636590

[Moritz Friedrich]

No success with switching to vanilla.
I should mention I am using 0.70-dev right now...

[Moritz Friedrich]

When comparing the token generated at the server and the client, I can see a pattern:

First try
Server: _aNRp8doIko-eEJxUbgyCXfl
Client: 6U0tpPQQ-7ZC7bLRg2GVnbsOHa6GHkLGR_C8

Second try
Server: m9A1Lnf7efV78dRuLAhKJ2zh
Client: WV8qGiVr-g555xVnuD1QZHWcavkB_ateMKX4

Third try
Server: ocShckErFsoLYVY_duiBP5ug
Client: bT4diTiU-9pQlbtfwLeJy1ALCSVoM2xLZe_4

So the scheme by which those are produced seems to be off. No idea how to mince this into a solution, but hey. It's something!

[Moritz Friedrich]

Okay, I solved it myself - seem to not have saved the new cookie domain correctly.
Someone should write a few guides on migrating... Maybe I'll do it tomorrow evening.

[julian]

@Moritz-Friedrich said:

Weird enough, I just realized that at the old subdomain (as a CNAME) logging in is still possible...

Default this is not set to anything, so this doesn't need to be set... afaik