Incorrect URL after login
-
@baris In my config.json I have this setup:
{ "url": "http://forums.mydomain.com", "secret": "REDACTED", "database": "mongo", "port": "4567", "mongo": { "host": "127.0.0.1", "port": "27017", "username": "nodebb", "password": "REDACTED", "database": "nodebb", "uri": "" } }
I have a reverse proxy setup with Nginx, it does SSL offloading.
I'm using Debian 9.
CertBot setup SSL inside of Nginx for me.I don't think my nginx configuration is at fault because everything else works except for the 'landing page' after logging in. What are your thoughts?
Thanks for your help!
-
@baris Changing it to that results in an error when I try to log in. After providing correct credentials, the URL becomes:
https://forums.mydomain.com/login?error=csrf-invalid
And the error message displayed is:Login Unsuccessful We were unable to log you in, likely due to an expired session. Please try again
-
I've also tried rebooting the server - and clearing my cookies for the site, same result.
-
@wayne-workman please share your nginx config
-
Just share whatever files you configured specifically for NodeBB.
-
This file is the only one I have edited by hand:
/etc/nginx/sites-available/default
the only parts I changed were the ones where you seeproxy_pass
The rest, certbot touched, or it's default config for debian 9.
For what it's worth, I really don't think the nginx config is at fault here... It works perfectly fine for everything else in NodeBB - the only issue is the landing page immediately after login.
## # You should look at the following URL's in order to grasp a solid understanding # of Nginx configuration files in order to fully unleash the power of Nginx. # https://www.nginx.com/resources/wiki/start/ # https://www.nginx.com/resources/wiki/start/topics/tutorials/config_pitfalls/ # https://wiki.debian.org/Nginx/DirectoryStructure # # In most cases, administrators will remove this file from sites-enabled/ and # leave it as reference inside of sites-available where it will continue to be # updated by the nginx packaging team. # # This file will automatically load configuration files provided by other # applications, such as Drupal or Wordpress. These applications will be made # available underneath a path with that package name, such as /drupal8. # # Please see /usr/share/doc/nginx-doc/examples/ for more detailed examples. ## # Default server configuration # server { listen 80 default_server; listen [::]:80 default_server; # SSL configuration # # listen 443 ssl default_server; # listen [::]:443 ssl default_server; # # Note: You should disable gzip for SSL traffic. # See: https://bugs.debian.org/773332 # # Read up on ssl_ciphers to ensure a secure configuration. # See: https://bugs.debian.org/765782 # # Self signed certs generated by the ssl-cert package # Don't use them in a production server! # # include snippets/snakeoil.conf; root /var/www/html; # Add index.php to the list if you are using PHP index index.html index.htm index.nginx-debian.html; server_name _; location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. proxy_pass http://127.0.0.1:4567; } # pass PHP scripts to FastCGI server # #location ~ \.php$ { # include snippets/fastcgi-php.conf; # # # With php-fpm (or other unix sockets): # fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; # # With php-cgi (or other tcp sockets): # fastcgi_pass 127.0.0.1:9000; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} } # Virtual Host configuration for example.com # # You can move that to a different file under sites-available/ and symlink that # to sites-enabled/ to enable it. # #server { # listen 80; # listen [::]:80; # # server_name example.com; # # root /var/www/example.com; # index index.html; # # location / { # try_files $uri $uri/ =404; # } #} server { # SSL configuration # # listen 443 ssl default_server; # listen [::]:443 ssl default_server; # # Note: You should disable gzip for SSL traffic. # See: https://bugs.debian.org/773332 # # Read up on ssl_ciphers to ensure a secure configuration. # See: https://bugs.debian.org/765782 # # Self signed certs generated by the ssl-cert package # Don't use them in a production server! # # include snippets/snakeoil.conf; root /var/www/html; # Add index.php to the list if you are using PHP index index.html index.htm index.nginx-debian.html; server_name forums.mydomain.com; # managed by Certbot location / { # First attempt to serve request as file, then # as directory, then fall back to displaying a 404. proxy_pass http://127.0.0.1:4567; } # pass PHP scripts to FastCGI server # #location ~ \.php$ { # include snippets/fastcgi-php.conf; # # # With php-fpm (or other unix sockets): # fastcgi_pass unix:/var/run/php/php7.0-fpm.sock; # # With php-cgi (or other tcp sockets): # fastcgi_pass 127.0.0.1:9000; #} # deny access to .htaccess files, if Apache's document root # concurs with nginx's one # #location ~ /\.ht { # deny all; #} listen [::]:443 ssl ipv6only=on; # managed by Certbot listen 443 ssl; # managed by Certbot ssl_certificate /etc/letsencrypt/live/forums.mydomain.com/fullchain.pem; # managed by Certbot ssl_certificate_key /etc/letsencrypt/live/forums.mydomain.com/privkey.pem; # managed by Certbot include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot } server { if ($host = forums.mydomain.com) { return 301 https://$host$request_uri; } # managed by Certbot listen 80 ; listen [::]:80 ; server_name forums.mydomain.com; return 404; # managed by Certbot }
-
-
Have you tried clearing your cookies?
-
@baris said in Incorrect URL after login:
Change "url": "http://forums.mydomain.com" to "url": "https://forums.mydomain.com" That should fix the problem. The url property should exactly match the url you are using to access the site.
Change "url": "http://forums.mydomain.com" to "url": "https://forums.mydomain.com" That should fix the problem.
This solves the problem surely for me. bute it needs to set some Sentence in nginx.conf.
-
Any other ideas on this? I think probably this is being caused by the URL field in the config.json file not being what users use - but my problem is when I set it to
https
it breaks the site entirely. How do I set it up so that Nginx can do SSL and this not be a problem? -
@wayne-workman Can I see the contents of
/etc/letsencrypt/options-ssl-nginx.conf
? I've never personally used certbot to handle nginx configuration, I prefer to do it myself.Here are the recommended configs for nginx: https://docs.nodebb.org/configuring/proxies/nginx/
-
@julian The big benefit of using certbot is it sets up a cron job and that job will automatically get you a new cert when your previous one is close to expiring.
root@debian:/home/wayne# cat /etc/letsencrypt/options-ssl-nginx.conf # This file contains important security parameters. If you modify this file # manually, Certbot will be unable to automatically provide future security # updates. Instead, Certbot will print and log an error message with a path to # the up-to-date file that you will need to refer to when manually updating # this file. ssl_session_cache shared:le_nginx_SSL:1m; ssl_session_timeout 1440m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS";
-
@julian I found this: https://github.com/NodeBB/NodeBB/issues/4734
Using the certbot configuration, I edited/etc/nginx/sites-available/default
Leaving the certbot managed parts as they are, my custom config looks like this now:
proxy_set_header X-Forwarded-Proto $scheme; location / { proxy_pass http://127.0.0.1:4567; }
The special part is the x-forwarded-proto line, that's what I was needing all along.
And in
/home/nodebb/nodebb/config.json
I'm setting the URL with https:{ "url": "https://forums.mydomain.com", "secret": "<REDACTED>", "database": "mongo", "port": "4567", "mongo": { "host": "127.0.0.1", "port": "27017", "username": "nodebb", "password": "<REDACTED>", "database": "nodebb", "uri": "" } }
This resolved my problem.