securing admin login only

Thanks for your assistance with this. Yes, I can use the curl command
curl secure.mydomain.com. It brings up the text of my home page.

sorry then. whatever is causing your Subdomain: no must be a different problem than what i was seeing.

this isn’t a real solution, but you can hack the plugin to force it to treat the URL as a subdomain. i don’t know what kind of side-effects this might have…

in the file wordpress-https/lib/WordPressHTTPS.php, line 205 should look like this:
$subdomain = false;

i think that if you change that to:
$subdomain = true;

then it will always treat the secure URL as a valid subdomain (whether it is or not).

might be worth trying that, then re-saving the settings in the plugin’s admin page, restart services on the server, clear your browser’s cookies for your secure and non-secure domains and try it all again.

Thanks so much! I will give this a shot. Here’s to hoping it works.

Determining if two domains truly share a common domain by only using string comparisons is not possible. When comparing two domains, it’s likely that pieces of the domains will match. It’s impossible to determine if that commonality is really a shared domain without knowing all possible top-level and second-level domains. That would require maintaining arrays of top-level and corresponding second-level domains in the code to check against. Due to the rapid change of domain name rules, it would be quite tedious to do that. For example, .uk has many, varying second-level domains.

maybe i’m not taking something into account.

do you mean that for the purposes of this plugin it wouldn’t work to call anything that looks like xxx.abc.def.gh (where xxx could be any arbitrary string) a subdomain of abc.def.gh?

in other words, if there is a hostname and then a dot and then some arbitrary domain name string and you are comparing that to another host that is identical except for the hostname and dot, wouldn’t it always work to call the first one a subdomain of the second for the purposes that this plugin serves?

sorry if i am being dense.

The problem isn’t determining if domain A is a subdomain of domain B. The problem is determining what the common domain is between the two domains so that you can then use that common domain as the domain for the cookie. The only reason the subdomain check is done is so the plugin knows to create the extra cookies when logging in. If the plugin can not determine the base domain, it doesn’t work anyway. Using simple string comparisons, you can never say for sure what the base domain is.

ahhh so.

now i get it. thanks for the explanation.

so now i am in production, behind cloudflare, and i am back to subdomain: no, and only getting a cookie (i believe) for the secure host and not sitewide. so i don’t appear as logged in (no admin bar) on the http host.

the problem i now see, i believe identical to @onerock, is not the hostname problem that i solved on my test platform. it is directly and repeatably the result of running the site behind cloudflare. if i have the http host being proxied by cloudflare, then the plugin gives me subdomain: no and i get no admin bar after logging in. if i bypass cloudflare for the http host, i get subdomain: yes and everythign works as expected.

among other things, cloudflare works as a reverse proxy. mike, do you think that changing the proxy setting in the plugin to auto or yes would have the right effect here? what does that proxy setting do?

@pjv – You have described exactly what I am experiencing.

i tried it with proxy set to yes.

and the plugin did recognize the HTTPS host as a subdomain.

but it still only sets logged-in cookies for the HTTPS host when the HTTP host is being proxied by cloudflare.

i have inspected the cookies that are set. with the HTTP host bypassing cloudflare, the plugin sets logged-in cookies for both the HTTP and HTTPS hosts. when i put the HTTP host behind cloudflare, it only sets logged-in cookies for the HTTPS host.

there are no changes whatsoever in the URLs between these two cases. the HTTPS host is always configured to bypass cloudflare. the only thing that changes is whether or not the HTTP host is being proxied by cloudflare.

on further experimentation, i was wrong about the proxy setting having any effect on the plugin recognizing the HTTPS host as a subdomain. i hadn’t realized how much “cleaning up” i need to do to see the result of changing things clearly: clearing caches, saving settings, restarting the php-fpm process… anyway, now that i know all that, i can see that the proxy setting has no effect.

when i have the HTTP host proxied by cloudflare the plugin will not set a domain-wide cookie.

given that the HTTPS host is a simple subdomain of the HTTP host, i’m sure that there has to be a relatively simple fix for this. mike: is there anything that i can do to make it easy for you to diagnose? i can set up a user on my site and/or do any experiments that you want to suggest and log results.

i’m also willing to dig around in the plugin’s code and try things if you could point me in the direction of where to start. i’ve looked through it, and i write code, but not php and i have never done a wp plugin, so the whole structure is a little bewildering to me. i’m thinking that it has to be somewhere in the code that is validating the subdomain, but for the life of me i can’t imagine what difference it can make having the HTTP host proxied by cloudflare. it’s still the same URL, same hostname, same basename.

The proxy setting is for bad proxies that don’t properly set the X-Forwarded headers. That is all. You would know if this was the case because nothing would work properly without that setting on Yes.

I don’t know what you’re talking about with “cleaning up” but you’re probably experiencing redirect caching issues in Google Chrome, not your server.

You’ve already identified the code that determines if the site a subdomain or not. The subdomain check is done upon installation/activation and when the settings are saved. The code simply isn’t working in your setup for one reason or another.

After researching this issue, I came to the conclusion that the best way to handle these situations is to manually set the cookie domain in the wp-config.php. Change it to ‘.yourdomain.com’ to get a site-wide cookie set.

I am currently working on improving this part of the code and will eventually remove the need for cURL requests to validate the cookie domain.

thanks, i had no idea you could set the cookie domain in wp-config.

that seems to be working for me.

Thank you for the set cookie domain tip. Adding this to the config file fixed the same problem for me that pjv was having. Also, it fixed the post/page previews errors (I was receiving 404 errors).