Home | Setup | FAQ | History | Reset
Welcome to the homepage of the Admin SSL plugin for WordPress.
For a history of the plugin, please go here.
For setup instructions, please go here.
If you are having problems, please read the FAQ before posting.
If you need to reset Admin SSL, please go here.
The latest release, 1.5-b1, supports WordPress 2.8.
NB the only way I could get Admin SSL to work in WP 2.6+ was to get it to disable the new WordPress authentication cookies, and use the ones from 2.5.1. I personally prefer SSL than the cookie weirdness of 2.6+, but it's up to you.
If I could be cheeky, and you would like to make a donation (for all my hard developing!), please use the PayPal donate button below:
Features
- Works with WordPress 2.2 – 2.7 (using both Private and Shared SSL).
- Works with WordPress MU 1.3+ (using Private SSL only).
- Forces wp-login.php, wp-admin/profile.php and wp-admin/users.php to be secured. This cannot be turned off.
- Additional pages and directories to be secured (e.g. wp-admin/) can be defined on the configuration page.
- Other options can be defined on the new configuration page.
- Reset, debug and test modes for troubleshooting.
Downloads
The following downloads are hosted by wordpress.org.
1.4.1 – The latest stable version, with all the above features.
You can also download the development version (1.5-b1), which contains bugfixes and new features as I include them.
If you prefer, you can use the SVN repository. The releases are in the 'tags' subdirectory, the development version in 'trunk'.
Known Issues
- Admin SSL has 'erratic' behaviour when WordPress is not installed in the same directory as the WordPress URL. This is because of the way the WordPress canonical redirection functions work. I have not yet been able to overcome these.
The login page (and other admin pages) can be secured, but nothing on the site side.
Screenshots
Secure login page.
Secure plugins screen, with Admin SSL enabled.
design © bcg mmviii
I’m testing this plugin on our VPS with a shared SSL cert.
The shared SSL cert. is attached to the main domain on our VPS, PodVenturesMedia.com (a WordPress site).
The plugin version is 1.3.2.
My Browser is FireFox v3.0.3.
Under the Admin SSL settings page, the
Shared SSL URL is: https://podventuresmedia.com/wp-admin/
The test site on the VPS is Hush-T-Scape.com running WordPress 2.6.3.
When I log into the dashboard at http://www.hush-t-scape.com
the dashboard opens but without an SSL lock.
When I try to log into https://www.hush-t-scape.com (securely)
I get giberish as expected.
Any help you could provide would be greatly appricated
as we’d like to use this plugin and see it’s value in securing
a WordPress site.
John
Hi John
The default behaviour of Admin SSL is to secure the login process and user profile pages, not the entire wp-admin folder.
It is possible to do the latter, but I felt the performance hit is not worth securing every single page, but only those with passwords/confidential information on.
Can you confirm that the login process is secured with your Shared SSL?
bcg
No I cannot verify the “lock” at the bottom right
using FireFox indicating that the connection is not secure.
The test setup on the VPS with the Shared SSL Cert on PodVenturesMedia.com
a) we are testing hush-t-scape.com/wp-admin
b) the “umbrella” company is podventuresmedia.com so the SSL is issued to it and NOT to the particular URL being tested. It is a “shared SSL” cert.
c) there are MANY URLs on the VPS with their own account and under the company – that will use this plugin (assuming it works).
1) We are wanting to use the plugin with the Shared SSL Cert for any of the WordPress sites on the VPS.
2) We’re only needing to protect the login and as the plugin has been designed to do.
Other possibly useful information:
And when I logout, the URL is:
https://hush-t-scape.com/wp-admin/ and with a “lock” in FireFox and on the screen with the expected Warning: Unknown: open_basedir restriction in effect.
When I attempt to log back in at http://hush-t-scape.com/wp-admin/
It logs me in automatically without asking for my password
which is not been set to be “saved.” ???
Note:
Under the settings for the Admin SSL plugin and
for the Shared SSL URL
Per our tech support at our VPS hosting company,
it is “https://hush-t-scape.com/wp-admin.
They said that although the cert. is issued to podventuresmedia.com
which is the main site on the VPS and our company URL,
the plugin’s Shared SSL URL setting should be set in Hush-T-Scape.com for the site that’s using the plugin:
https://hush-t-scape.com/wp-admin.
I really do appricate your work on the plugin and
your response to my email.
John
The plugin is great. I found one issue wth version 1.3.2. If you are using nextgen gallery and you select show slide show, it invokes the jw image rotator (flash) with an url feed like
http://talon.bogometer.com/wp/wp-content/plugins/nextgen-gallery/nggextractXML.php?gid=7
This will invoke the nextgen gallery plugin file nggextractXML.php.
It will go for wp-load.php in 2.6 which causes the init function of admin_ssl in https.php to run. That sets up as_ob_handler to run later as an output filter. When as_ob_handler is subquently called, the routine get_option (for get_option(”home”) or get_option(”siteurl”)) is not loaded for some reason. That causes the generation of the xml to fail for nextgen and so no slide show
I kludged around it with
if (!defined(’get-option’)) return $buffer;
But you may want to look into it.
@Shane:
Thanks very much – I’ll have a look into it!
BCG
Hi,
I need to secure an order page here:
http://www.logoquality.com/order/logo-design/order-logo/
The problem I have is that my wordpress is in the directory wordpress.
When I put my URL to secure in the box like:
order/logo-design/order-logo/
The Admin SSL tries to secure:
https://www.logoquality.com/wordpress/order/logo-design/order-logo/
This does not exist like this though.
Can I have SSL work on this page or not? What do I need to get it to work?
Thanks.
@Simon
Admin SSL will not work when you have wordpress installed in a different directory to the URL – strange things happen in the interaction between Admin SSL and WordPress, as you have discovered. I have spent a long time trying to work around this, but simply cannot get it to work.
BCG
Using Stable tag: 1.3.2
I tried to reset the plugin http://www.kerrins.co.uk/blog/admin-ssl/reset/
Second way: visit admin-ssl-reset.php
I and it appeared to work. The plugin was disabled at the time, but when I re-enabled it, the Admin SSL option was gone. I tried deactivating, deleting the plugin, and re-extracting it, but that didn’t work.
I was going trying everything I can think of because it doesn’t appear to be working. I’m using WordPress 2.6.5.
I’m trying to use shared SSL on BlueHost.com in order to get WP e-Commerce to work http://www.instinct.co.nz/e-commerce/securing-wordpress
BlueHost can only do a dedicated SSL for you primary domain, which is not the one I’m using. I don’t know if that has anything to do with why SSL Admin won’t work either. I am using the shared SSL URL.
I say this is not working because none of my pages appear to be encrypted, except for when I logout I get a 404 page on found error and the secure URL with my account name and WordPress site name in the URL show up.
In WP e-Commerce plugin admin panel there is a page to configure customer payment options, but it shows up as
Note: Please put this link to your Google API callback url field on your Google checkout account: http://mydomain/index.php
Google won’t accept a URL without an https
I have tried using the same shared URL string that is used to configure Admin SSL, but that returned errors.
Again, I have the problem that I have messed with this until the Admin SSL options disappeared from the Admin panel for the Plugins.
Any suggestions? :’(
@Amapola
Have you tried the third way? If you change the ‘RESET’ constant to ‘true’, and then enable the plugin, this will ensure that all Admin SSL’s options are reset – the other methods may not be working for you.
Other than that – I have no experience of the e-commerce plugin, so I can’t really suggest anything. Admin SSL works fine with Shared SSL on its own, but interaction with other plugins may well cause things to act in a strange way.
BCG
Well, it looks like I’ve mucked up things pretty well now. I tried to sign it, but it says:
“Redirect Loop
Firefox has detected that the server is redirecting the request for this address in a way that will never complete.”
I deleted the plugin, but WordPress didn’t deactivate it. I got the same error when trying to sign in again.
I tried re-extracting the plugin, and then the Third Reset Method:
Changed define(“RESET”,false); to define(“RESET”,true);
I guess I will have to hack the plugin out of the MySQL database using phpMyAdmin, or restore my database from backup.
@Amapola
The redirect error normally comes when there is a spelling mistake or something in the Shared SSL URL – there hasn’t been a redirect bug in Admin SSL for several months now.
The other way of stopping the redirection is simply to delete the Admin SSL files, and use one of the option manager plugins to remove all the Admin SSL options from the database.
BCG
I tried deleting the plugin, but the site kept getting redirected the URL I had set in the SSL Admin configuration.
I figured I had some sort of database problem so I tried to restore from backup. That didn’t go very well.
Maybe it was a WordPress corruption problem, since it didn’t detect the plugin had been deleted, and deactivate it.
To make a long story short, I am in the process of rebuilding the site from scratch.
I should have known better than to test this out one of my live sites rather than a test site.
@Amapola
That is very strange, if you deleted the plugin, but the redirection was still happening?! Did you delete all references in the WP database to the Shared SSL URL?
BCG
So Far so good. Installed v1.3.2 on a new installation of WordPress 2.7 and it seems to work fine. All I was looking for was a redirect to HTTPS for logging in to WP-Admin and it works like a charm. Thanks for the great plugin!!!
When you enable the plugin with the gallery feature the gallery stops working. Seems like a bug just wanted to let you know.
Thanks – I’ll look into it.
Hi,
After enabling your plugin the slideshow feature of the nextgen gallery plugin stopped working. If I deactivate your plug-in the slideshow works again. I think there might be a bug somewhere.
Just to let you know…
happy new year
Just some additional info for you:
I think the problem is related with what Shane Hartman’s post mentioned… only I’m using the most recent version of nextgen gallery: and the file being causing problem is located in wp-content/plugins/nextgen-gallery/xml/imagerotator.php.
Hope it helps…
Is there a tag for 1.3.4 in SVN? If not, could you please add?
Thanks
@Jason:
I’ve committed a 1.3.5 and added a tag – can’t believe I forgot for 1.3.4!
@bcg: Sweet, thanks
Missed a bit on the tag location
I think I should have had some coffee when I got up this morning…
I am having trouble with mixed content errors on my secured pages because of the following 2 plugins:
Nextgen Gallery and Cforms. I’ve replaced Cforms for now, but would like to get Nextgen working. The Nextgen css file url in the header is the culprit. It is the only url (other than 2 Cforms urls) that isn’t referenced as https.
@NZ: I’ll try and look into it over the next few days. Cheers.
Thanks!
Forgive me if I’m being dense; I think this was covered in earlier in the thread, but I just want to be sure.
I’m using WordPress MU 2.7 (beta) and Admin-SSL 1.3.5. I’m running my WordPress MU install in directory mode (e.g. wordpress.foo.edu/bar) rather than subdomain mode (e.g. bar.wordpress.foo.edu). With Admin-SSL installed, the redirects work perfectly for the top-level, mother blog (the admin blog at wordpress.foo.edu) but all lower-level, daughter blogs (wordpress.foo.edu/bar/wp-admin/) throw 404 errors when I try and access them.
Everything redirects to https correctly, it’s just that the page won’t load. Based on your initial post and the comment thread, I’m guessing this relates to your comment that “Admin SSL has ‘erratic’ behaviour when WordPress is not installed in the same directory as the WordPress URL.” because of the WordPress rewrite voodoo.
So things are fine as long as you’re in the base directory for the mother blog, but once you get into a subdirectory for one of the daughter blogs, things fail because of the redirect issues?
Or should things work for the daughter blogs as well, and I should be hunting elsewhere for the solution to my 404 woes?
I figured out my issue. It turns out that the SSL-protected pages would not load because the ssl.conf information for that virtual host had “AllowOverride None” instead of “AllowOverride FileInfo Options”. Once I tweaked the setting and rebooted apache, htaccess was able to do its things, pages were redirected correctly and Admin-SSL worked like a dream.
@Ken – Great news. I’m having trouble getting time to troubleshoot some of the stuff people are posting on here, so I’m gladd you’ve sorted it.
Hi
When I try to use Admin SSL with WP 2.7 I get a funny redirect to my login page.
I use the a shared setup where I’ve made the alias “/wp”. When enabling shared ssl and type in this: “https://pregel.dk/wp/wp-admin”
the link is messed up and becomes: “https://pregel.dk/wp/wp/wp/wp-admin” which of course doesn’t work.
/T
@Thomas
Are you using the WordPress home in a different directory to the URL feature? It may be that that is the problem – if not it sounds like something else is going on.
BCG
I’m not sure if I understand you correctly but yes, I’ve got wordpress in one directory and my ssl virtual host is in an other directory. I’ve tried both making an alias on my ssl virtual host and copied the wp-admin directory directly under the ssl directory.
/T
@Thomas
Perhaps you could enable debug mode and email the debug log (instructions can be found on the site).
bcg
Dear Sir,
I tried to use your plugin with shared ssl certificate, however unfortunately I get the infinite loop problem before being able to access the login page.
The path to wp-admin should be definitely correct, however the HTTPS detection fields are HTTPS and ON which sounds me wrong. I have no idea how to set them though!
You can have a look at my debug.log here EDITED
Thank you very much for your support!
@alde
I’ll email you…
I’ve run into an intermittent problem with xmlrpc and Admin SSL.
Blog runs fine w/o SSL. Also runs fine w/Admin SSL. I’ve added “xmlrpc.php” to the list of secured files, though, and that’s where I have a problem.
With “xmlrpc.php” secured, my blog sometimes ships out malformed XML responses to blog editors when they are trying to retrieve a list of posts. I’ve notice, for example, a missing tag.
This does not happen all the time. For example, on one blog I can get a refresh of the list from the blog editor to succeed if I limit it to 1 item, but it fails (with the missing tag above) when I include the 3rd item. When I disable Admin SSL the blog editor gets good data from my server.
Any ideas on how Admin SSL might be interacting so oddly with xmlrpc? Any suggestions on how to debug this problem?
I think I found the xmlrpc problem.
It turns out that Admin SSL assumes that it should rewrite self-referencing http URLs in the outbound buffer so that they point to https. Normally this is a good idea (avoids many warnings from the browser). But it is a bad idea when the outbound buffer is an XML file which WordPress already assumes to be of a given length. Essentially, the rewritten buffer was too long and some tags (including the closing tag) were getting cut off.
My suggestion: explicitly exempt xmlrpc.php from the substitution. I’ve done this rather crudely, I’m sure you may have a prettier way of accomplishing the same thing. Here’s the patch that worked for me:
In https.php replace…
$buffer = str_replace($replace_this,$with_this,$buffer);
with…
if(strpos(req_uri(),”xmlrpc.php”) === false) { $buffer = str_replace($replace_this,$with_this,$buffer); }
Presto, my blog editor can now parse the XML being returned by xmlrpc.php.
By the way, this also explains why the problem did not always occur. Some of the blogs didn’t have any images in the posts. No images meant no local URL references. No such references meant no substitutions. No substitutions meant no changes in response length. Everything worked in those cases.