Invalid session

singhnsk

@julian In the documentation, why the X-Forwarded-Proto not shown in the very first sample - Below is the basic nginx configuration for a NodeBB build running on port 4567?

I think that is the one which anybody will notice at the first visit to that page. I was needed to use find in page to get the exact code I was needed to include into the file. Or is it so that it is only needed on HTTPS installs?

codecowboy

@julian I'm getting this too. Please can you / someone post a working config for apache2?

My apache version is:

Server version: Apache/2.4.7 (Ubuntu)

Apache config:

<VirtualHost *:80>
 
        ServerAlias mydomain.com
        ServerName mydomain.kickasskandy.com

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www

        ErrorLog ${APACHE_LOG_DIR}/kommunity.error.log
        CustomLog ${APACHE_LOG_DIR}/kommunity.log combined

ProxyRequests off

<Proxy *>
    Order deny,allow
    Allow from all
</Proxy>

RewriteEngine On

RewriteCond %{REQUEST_URI}  ^/socket.io            [NC]
RewriteCond %{QUERY_STRING} transport=websocket    [NC]
RewriteRule /(.*)           ws://127.0.0.1:4566/$1 [P,L]

ProxyPass / http://127.0.0.1:4566/
ProxyPassReverse / http://127.0.0.1:4566/

</VirtualHost>```

codecowboy

@chrismccoy did you resolve this? If so, can you post a working apache config? Thanks!

julian

@codecowboy For Apache server, the additional protocol forwarding is done like so:

<VirtualHost *:80>
    RequestHeader set X-Forwarded-Proto "http"
    …
</VirtualHost>

<VirtualHost *:443>
    RequestHeader set X-Forwarded-Proto "https"
    …
</VirtualHost>

codecowboy

@julian

Unfortunately this hasn't resolved things. Do I need the SSL virtualhost?

codecowboy

@julian I would attach apache debug logs but I dont have enough privileges

julian

@codecowboy said in Invalid session:

Unfortunately this hasn't resolved things. Do I need the SSL virtualhost?

If you use SSL, then yes, otherwise, no. Also ensure you haven't set cookieDomain in your NodeBB settings.

chrismccoy

yes this resolved it for me also.

codecowboy

I am still stuck on this :(. What does this particular http header even do and how does it relate to sessions / csrf tokens?

If anyone is willing to help please PM me. It's getting urgent and I might just have to abandon NodeBB entirely which I would rather not do.

codecowboy

@julian I would check the cookie domain settings if I could log in - which I can't.

jarey

@codecowboy can't it be specified by the config.json file? maybe you can just change it there. (i'm talkiing about the cookieDomain setting of NodeBB).

<VirtualHost *:80>
RequestHeader set X-Forwarded-Proto "http"
…
</VirtualHost>

After setting the RequestHeader set X-Forwarded-Proto "http" header in Apache, have you restarted the process? Do you see any errors on logs? Maybe Apache is not running correctly or something. It is rare that @chrismccoy got it fixed with that piece of config and that it is failing in your scenario.

codecowboy

I tried some more apache debugging and am getting the following:

[Tue Aug 02 07:57:05.141920 2016] [authz_core:debug] [pid 3272] mod_authz_core.c(828): [client 86.190.168.236:50732] AH01628: authorization result: granted (no directives), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142035 2016] [proxy:debug] [pid 3272] mod_proxy.c(1104): [client 86.190.168.236:50732] AH01143: Running scheme http handler (attempt 0), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142077 2016] [proxy:debug] [pid 3272] proxy_util.c(2072): [client 86.190.168.236:50732] AH00944: connecting http://127.0.0.1:4566/language/en_GB/language.json?v=38efc154-50a9-4518-bac1-62d8900bc869 to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142093 2016] [proxy:debug] [pid 3272] proxy_util.c(2206): [client 86.190.168.236:50732] AH00947: connected /language/en_GB/language.json?v=38efc154-50a9-4518-bac1-62d8900bc869 to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142283 2016] [authz_core:debug] [pid 3166] mod_authz_core.c(828): [client 86.190.168.236:50730] AH01628: authorization result: granted (no directives), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142375 2016] [proxy:debug] [pid 3166] mod_proxy.c(1104): [client 86.190.168.236:50730] AH01143: Running scheme http handler (attempt 0), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142412 2016] [proxy:debug] [pid 3166] proxy_util.c(2072): [client 86.190.168.236:50730] AH00944: connecting http://127.0.0.1:4566/vendor/jquery/timeago/locales/jquery.timeago.en.js?_=1470121024713 to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.142446 2016] [proxy:debug] [pid 3166] proxy_util.c(2206): [client 86.190.168.236:50730] AH00947: connected /vendor/jquery/timeago/locales/jquery.timeago.en.js?_=1470121024713 to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.145968 2016] [authz_core:debug] [pid 3185] mod_authz_core.c(828): [client 86.190.168.236:50733] AH01628: authorization result: granted (no directives), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.146082 2016] [proxy:debug] [pid 3185] mod_proxy.c(1104): [client 86.190.168.236:50733] AH01143: Running scheme http handler (attempt 0), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.146149 2016] [proxy:debug] [pid 3185] proxy_util.c(2072): [client 86.190.168.236:50733] AH00944: connecting http://127.0.0.1:4566/socket.io/?EIO=3&transport=polling&t=LPA2fvh&sid=dEEm6u9K-ruZQXcpAAAi to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.146166 2016] [proxy:debug] [pid 3185] proxy_util.c(2206): [client 86.190.168.236:50733] AH00947: connected /socket.io/?EIO=3&transport=polling&t=LPA2fvh&sid=dEEm6u9K-ruZQXcpAAAi to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.203574 2016] [deflate:debug] [pid 3166] mod_deflate.c(849): [client 86.190.168.236:50730] AH01384: Zlib: Compressed 455 to 228 : URL /vendor/jquery/timeago/locales/jquery.timeago.en.js, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.220461 2016] [authz_core:debug] [pid 3166] mod_authz_core.c(828): [client 86.190.168.236:50730] AH01628: authorization result: granted (no directives), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.220590 2016] [proxy:debug] [pid 3166] mod_proxy.c(1104): [client 86.190.168.236:50730] AH01143: Running scheme http handler (attempt 0), referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.220627 2016] [proxy:debug] [pid 3166] proxy_util.c(2072): [client 86.190.168.236:50730] AH00944: connecting http://127.0.0.1:4566/vendor/jquery/timeago/locales/jquery.timeago.en-short.js?_=1470121024714 to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.220642 2016] [proxy:debug] [pid 3166] proxy_util.c(2206): [client 86.190.168.236:50730] AH00947: connected /vendor/jquery/timeago/locales/jquery.timeago.en-short.js?_=1470121024714 to 127.0.0.1:4566, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid
[Tue Aug 02 07:57:05.263389 2016] [deflate:debug] [pid 3166] mod_deflate.c(849): [client 86.190.168.236:50730] AH01384: Zlib: Compressed 351 to 186 : URL /vendor/jquery/timeago/locales/jquery.timeago.en-short.js, referer: http://kommunity.kickasskandy.com/login?error=csrf-invalid

codecowboy

@jarey I restarted apache and cant see anything useful in the logs relating to that header. I've pasted the logs in a previous post

codecowboy

@julian said in Invalid session:

cookieDomain

Is there a way to override cookieDomain in config.json? I think I may have set this option at some point in the admin dashboard.

pichalite

@codecowboy try updating the database. If you are using mongodb, run this

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

codecowboy

@pichalite said in Invalid session:

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

I have now deleted that field in the database, restarted NodeBB and this solved it.

Thanks @pichalite and @julian !!!

Please tell me where to add documentation about this so that others do not experience this pain. And trust me it was real pain. I cried into my cornflakes.

I would like to understand why having the cookieDomain set breaks things and how to integrate this into the updater - perhaps this could be my first contribution to the code? Surely if having this value set is going to render a forum unusable then it should either be fixed or the field should be removed in the most recent update script?

Thanks again.

julian

Honestly? The purpose of cookiedomain is to let you "genericise" the NodeBB cookie so you can read it (and its session) in another app sharing the same express secret. It's useful, but 99.999% of admins probably don't use it, and setting it can definitely cause problems.