securing admin login only

Disregard, I have resolved my issue. I missed the fact that I needed to put secure.mydomain.com in the SSL Host box and check the Force SSL Administration box. All of my admin pages are secure, but it hasn’t slowed anything down, so I am good with this.

Thanks for a great plugin.

After running this for a week, I am running into a few usability related issues. I am now attempting to only secure the WordPress Logins. I have found a few options to do this, but none seem to work for me. I believe that this is because I am using a sub domain for the HTTPS.

From https://www.thatsgeeky.com/2012/01/wordpress-ssl-login-page-without-ssl-admin/

I have attempted to edit wp-login.php:

Change line 565 for WP 3.4.2 of wp-login.php:
From: $secure_cookie = ”;
To: $secure_cookie = false;

Explictly request admin_url() to return the non SSL url by changing line 588 for WP 3.4.1 of wp-login.php:
From: $redirect_to = admin_url();
To: $redirect_to = admin_url(”,’http’);

Can you please offer some assistance with making only the logins secure.

Thanks in advance Scott

Is there any reason you aren’t securing the entire admin panel?

The main reason is that I cannot browse the website while logged in. This is causing hassles with things that I do as logged in and not logged in.

Why can’t you browse the site while logged in?

If I click the visit site button on the admin bar, I am redirected to https://MyDomain.com, not logged in. If I type in the address bar of an internet browser, https://Secure.MyDomain.com, I redirected to https://MyDomain.com, not logged in.

If you’re using a subdomain, you should be logged into both using a domain-wide cookie. Enable debug mode and check your browsers console for the debug output. Look for a line that says “Subdomain: Yes/No”. If it says no, try re-saving the WordPress HTTPS settings and see if it changes. If it says Yes, there’s a bug of some kind.

Thanks so much for your help.

I have verified that the following through debug, see below. After re-saving the info in the plugin, I am still not able to browse my site while logged in.

[BEGIN WordPress HTTPS Debug Log]
/wp-admin/ (line 629)
Version: 3.2.3
/wp-admin/ (line 630)
HTTP URL: https://MyDomain.com/
/wp-admin/ (line 631)
HTTPS URL: https://secure.MyDomain.com/
/wp-admin/ (line 632)
SSL: Yes
/wp-admin/ (line 633)
Diff Host: Yes
/wp-admin/ (line 634)
Subdomain: No
/wp-admin/ (line 635)
Proxy: No

i’m seeing the same issue with version 3.3.0, trying to do the same thing. i have a non-multisite install of wordpress and i need to run the admin on a secure subdomain.

when i activate and set up the plugin with the secure subdomain specified and both SSL admin and exclusive SSL options checked, much works as expected. when i go to the login page and the admin panel, it all redirects to the secure subdomain (secure.wr-test.local). when i click the “visit site” link, i get re-directed to the non-secure main domain (wr-test.local).

[and btw, i was having trouble with the preview button sending me to a 404 as mentioned in several other threads and i was able to fix that issue by putting “preview=true” into the URL filters box]

here is what doesn’t work as expected:

after logging in and then clicking on the “visit site” link, while browsing the site on the main non-secure domain, there is no admin bar at the top (i.e. i am not logged in on the non-secure host).

i am using nginx to serve this site. i have two virtual hosts set up: wr-test.local is listening on port 80 and secure.wr-test.local is listening on port 443

here is the debug log (subdomain remains “No” after re-saving HTTPS settings):

[BEGIN WordPress HTTPS Debug Log]
Version: 3.3.0
HTTP URL: https://wr-test.local/
HTTPS URL: https://secure.wr-test.local/
SSL: Yes
Diff Host: Yes
Subdomain: No
Proxy: No

continuing to work through this issue, i have one new update. in trying to determine why the plugin was not seeing secure.wr-test.local as a subdomain of wr-test.local, i dug down until i found the function isValid() inside of Url.php. when i read through the code in there, i realized that it was returning false because i am running all this on a test server and i had neglected to include the hostname secure.wr-test.local in the hosts file on the test machine, and it obviously does not resolve by dns.

as an aside, it seems a little strange to me to verify a subdomain by doing a curl on it. wouldn’t it make more sense to decide that secure.wr-test.local is a subdomain of wr-test.local purely on a string comparison basis?

anyway, now that i added that host to the hosts file, re-saved the settings in HTTPS admin, and cleared all the cookies and then re-logged in, the debug log now looks like this:

[BEGIN WordPress HTTPS Debug Log]
Version: 3.3.0
HTTP URL: https://wr-test.local/
HTTPS URL: https://secure.wr-test.local/
SSL: Yes
Diff Host: Yes
Subdomain: Yes
Proxy: No

but i still have the same issue. the cookie being set is not for the whole domain, but only for the secure.wr-test.local host. i still am not logged in on the insecure site front end, and i can also see in safari that there are only cookies stored for the secure.wr-test.local host and none for wr-test.local.

i am highly motivated to get this working and would be happy to test and report.

ignore the post just above. i re-started nginx and php5-fpm on the server and quit and re-started the browser and now everything is working fine. so the original problem does seem to have been the isValid() function returning false because i had forgotten to enter the hostname for the secure host into the test server’s host file. i hope that helps someone else.

I am on a production CentOS 6 server with Apache, but I am wondering if restarting services will fix it like it did for you.

i think it was the combination of getting the hosts file right and then restarting that fixed the problem i was seeing. i don’t think it was just the restart because i had done a lot of tweaking and restarting with no effect until i got the hostname issue sorted.

i’d still suggest to mike that he re-think validating the subdomain URL by connecting to it with curl as part of determining whether it is in fact a subdomain. so many ways that could go wrong in terms of connectivity at the time of the check, whether the user has curl installed or not, etc. it seems to me to make more sense to determine if a URL is a valid subdomain of another URL on a purely lexical basis.

that said, this is a GREAT plugin, so thanks mike for putting it out there.

You are right, it didn’t help out my situation. My debug logs always shows as Subdomain: no.

does your centOS box have curl installed?

can you run something like this from the command line on the server and get a valid http response?:

curl secure.mydomain.com