No WP login behind a Reverse Proxy. Just redirect loop.

Hi Bill,

I feel like you’re not defining the admin location in wp-config.php… which sounds sort of obvious from your description of it not getting there ??

Trying to think where in the chain this might be.

I *do* use Nginx Unit to pass based on uri match (for ‘/wp-admin/’ ) and this might be all you need to define (perhaps try doing so as location in nginx.conf)

Sorry — I can see that defined in your config at the top there now.

Try adding the following to your nginx.conf server directive – you’d need this in the frontend part:

server_name_in_redirect off;

This may be sufficient.

I think maybe your proxy pass should be at location /wp-admin/ within your frontend directives. But I’d like to see all of nginx.conf to be sure.

Hi Rob,

Thanks for helping out!

My configs are a mess with tons of comments & notes.
So I cleaned them up and pasted my front- and back-end nginx configs below. I’m hoping I didn’t fat-thumb the copy & paste!

frontend.mydomain.com.conf
	...
	map $http_upgrade $connection_upgrade {
		default upgrade;
		'' close;
	}
	upstream PHPFPM { server unix:/run/php-fpm.sock; keepalive 128; }
	upstream WP { server backend.mydomain.com:443; }
	...
	server {
		listen 192.168.1.50:443 ssl http2;
		server_name frontend.mydomain.com;
		root /dev/null;
		autoindex off;
		autoindex_exact_size off;
		autoindex_localtime on;
		index index.php index.html;
		...
		location ^~ /wordpress/ {
			proxy_pass https://WP/;
			expires -1;
			proxy_buffering off;
			proxy_cookie_domain frontend.mydomain.com $host;
			proxy_hide_header Access-Control-Allow-Headers;
			proxy_http_version 1.1;
			proxy_pass_header Access-Control-Allow-Origin;
			proxy_pass_header Access-Control-Allow-Methods;
			 more_set_headers "Access-Control-Allow-Origin: *";
			 more_set_headers "Access-Control-Allow-Headers: X-Requested-With, Content-Type, Authorization, Lang";
			 more_set_headers "Access-Control-Allow-Methods: POST,GET,PUT,DELETE";
			 more_set_headers "Access-Control-Allow-Credentials: true";
			proxy_redirect off;
			proxy_set_header Accept 'application/json';
			proxy_set_header Connection $connection_upgrade;
			proxy_set_header Content-Type 'application/json';
			proxy_set_header Host $http_host;
			proxy_set_header HTTPS on;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
			proxy_set_header X-Forwarded-Host $server_name;
			proxy_set_header X-Forwarded-Port $server_port;
			proxy_set_header X-Forwarded-Proto https;
			proxy_set_header X-Forwarded-Protocol https;
			proxy_set_header X-Forwarded-Server $host;
			proxy_set_header X-NginX-Proxy 'Y';
			proxy_set_header X-Real-IP $remote_addr;
			proxy_set_header X-Script-Name /wordpress;
			proxy_set_header X-SSL-Subject $ssl_client_s_dn;
			proxy_set_header X-SSL-Issuer $ssl_client_i_dn;
			proxy_ssl_certificate "/home/web/ssl/client.backend.crt";
			proxy_ssl_certificate_key "/home/web/ssl/client.backend.key";
			proxy_ssl_name backend.mydomain.com;
			proxy_ssl_session_reuse off;
			proxy_ssl_trusted_certificate "/home/web/ssl/ca.crt";
			proxy_ssl_verify off;
			server_name_in_redirect off;
			...
		}
		...
	}

backend.mydomain.com.conf
	server {
		listen 192.168.1.50:443 ssl http2;
		server_name backend.mydomain.com;
		root /home/web/wordpress;
		index index.php;

		hide_server_tokens on;
		security_headers on;
		security_headers_referrer_policy unsafe-url;
		set $CSP_HOSTS "https://*.mydomain.com";
		set $CSP "default-src 'self' https://*.mydomain.com;";

		ssl_client_certificate "/home/web/ssl/ca.crt";
		ssl_certificate "/home/web/ssl/server.backend.crt";
		ssl_certificate_key "/home/web/ssl/server.backend.key";
		ssl_verify_client off;
		ssl_verify_depth 2;

		location = /favicon.ico { log_not_found off; access_log off; }
		location = /robots.txt { allow all; log_not_found off; access_log off; }
		location / { try_files $uri $uri/ /index.php?$args; }
		location ~ \.php$ {
			include fastcgi.conf;
			fastcgi_param SSL_CLIENT_CERT $ssl_client_raw_cert if_not_empty;
			fastcgi_param SSL_CLIENT_FINGERPRINT $ssl_client_fingerprint if_not_empty;
			fastcgi_param SSL_CLIENT_VERIFY $ssl_client_verify if_not_empty;
			fastcgi_intercept_errors on;
			fastcgi_pass PHPFPM;
			fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
		}
		location ~* \.(js|css|png|jpg|jpeg|gif|ico)$ { expires max; log_not_found off;}
		...
	}

With that config I see the same behavior as in my OP –
– login OK direct to backend, redirect to admin panel
– login redirect back to login, no admin panel access

Bill

Most of that config was cribbed together from other posts. I don’t vouch for much of it beyond
(a) I’ve seen it before
(b) I can get to the login screen in both cases.

I just tried a couple of the other backends mentioned in that other, closed issue.

Login & access to admin panels in basic installs of Drupal & Octobercms work both direct to the backend and through the reverse-proxy frontend. I don’t know a thing about Strappi other than it’s a Node app, and I don’t want to mess with it to try.

@robscott

> But I’d like to see all of nginx.conf to be sure.

If that’s not (all of) what you’re looking for, just let me know.

Thanks!

Sorry for delay – I had a week out of office.

I wonder if you’re looping http <> https from backend to frontend.

Alternatively your issue might be how the location /wp-admin/ is handled (i.e. where wp-login.php attempts to redirect you to).

If you attempt to load /wp-admin/ after logging in – does it work?
What if you add /wp-admin/index.php ?

Is there any reason you dislike Nginx Unit for this?

Hi,

> I wonder if you’re looping http <> https from backend to frontend.

I've set everything for https-only.

frontend is https.
backend is https.
certs are verified in both directions.
etc etc
I can see no trace of any traffic, or links, as http.

Other than setting that up properly, is there something else you have in mind to check for that "looping" ?

> Alternatively your issue might be how the location /wp-admin/ is handled (i.e. where wp-login.php attempts to redirect you to).

> If you attempt to load /wp-admin/ after logging in – does it work?

nope.

go to url    -> https://frontend.mydomain.com/wordpress/wp-login.php
Enter credentials + click LogIn
redirects to -> https://frontend.mydomain.com/wordpress/wp-login.php

go to url    -> https://frontend.mydomain.com/wordpress/wp-admin/
redirects to -> https://frontend.mydomain.com/wordpress/wp-login.php?redirect_to=https%3A%2F%2Ffrontend.mydomain.com%2Fwordpress%2Fwordpress%2Fwp-admin%2F&reauth=1

> What if you add /wp-admin/index.php ?

go to url    -> https://frontend.mydomain.com/wordpress/wp-admin/index.php
redirects to -> https://frontend.mydomain.com/wordpress/wp-login.php?redirect_to=https%3A%2F%2Ffrontend.mydomain.com%2Fwordpress%2Fwordpress%2Fwp-admin%2Findex.php&reauth=1

> Is there any reason you dislike Nginx Unit for this?

It's far less widely in use than nginx.
Its docs are thin, as are posts; nginx + php-fpm are expansive and easily found.
TLS 1.3 cipher suite support is (still?) missing from current release.

And, this should work with WP.
The fact that it's not documented @WP, doesn't seem to work out of the box, and there seems to be noone, so far as I've found, that's got it working is a big, red flag for me.

All the needed guesswork suggests to me problems with rewrite assumptions, and makes me question what's under the hood.

I’ve set everything for https-only.

This wasn’t my point – my point was about how you’re proxy-ing; and this is port specific.

I don’t fully understand your use-case, nor your expectation re documentation for what looks like an edge case setup. Can you describe why you expect this setup to be documented? What’s the benefit of the split between admin and front-end?