Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm working on a site that requires an https secured admin area and a secure front-end area as well where private information will be shown. My preference for user login is an Ajax-enabled widget that can be shown on every page of the site, but I'm not able to make it work when passing submitted form data from the non-secured pages to the login page.

I started by using the Login With Ajax plugin, which with a few modifications, plays well with SSL for the most part, and it works fine when logging in from a page that's being accessed by https... and it also works fine when FORCE_SSL_ADMIN is turned off. But when trying to log in from the widget on a non-secured page with FORCE_SSL_ADMIN on, I can't get an response from the server.

Are there any existing plugins which solve this problem? And if not, anyone have any solutions? Maybe a secured form embedded in an iframe is my best idea so far... just thinking that there must be an easier way.

*Edit: Offering Bounty*

I'm adding a bounty to this question because I'm still curious. I worked around this in my project by just giving up on the widget and displaying a link to the wp-login page. But being able to embed a secure login form on a non secure page would be a much better solution. I'll award the bounty to anyone who can show code that would work to make that happen, or point me to a plugin that already does this.

share|improve this question
    
So you have a non-secure page where you display the form that will submit to a secure page? The problem here is that an man-in-the-middle attacker could change your unsecured login page so the login form submits to his own server, and thus gets all login and password information. –  Jan Fabry Oct 11 '10 at 6:53
    
Yeah, as a model for what I was hoping to do, I was looking at the traditional banking website, where there's a secure login form embedded as the src of an iframe on a page which is not necessarily secured. After reading your link and other security critiques such as (this one)[my.opera.com/yngve/blog/show.dml/281609], I think I agree that its not necessarily a good idea. But I'll still leave my bounty up till I figure out how to make it work. –  goldenapples Oct 11 '10 at 19:31
    
Small editing tip: for embedding links, you do it the other way around, so it becomes [link text](link destination). –  Jan Fabry Oct 11 '10 at 19:53
    
Too bad the src of the iframe could be modified in the unencrypted main page. Security... Can't live with it, can't live without it. –  dgw Oct 12 '10 at 23:11
    
If someone manages to take control of some nameservers and spoof my site... guess that's beyond my control. Of course they could also spoof the security certificate as well, I would think. I'm not using one of the extended validation certificates, just standard "blue bar" encryption. –  goldenapples Oct 17 '10 at 6:02

5 Answers 5

There are ways of doing it; this way, for instance. My guess is that Login With Ajax isn't using all of the techniques described in that article, and some browser security feature is blocking it. Try getting in touch with the developer and suggesting improvements, with a pointer to that article.

share|improve this answer
    
I will read over those notes and see if they help me. This one is the only one that I'm not sure of... not quite sure why its necessary and whether wp-login.php's redirect_to action fits this description: The secure URL where the form is submitted to should always return a 302 redirect back to a non-secure URL. –  goldenapples Oct 11 '10 at 19:36
1  
Returning the user to a non-secure URL as a result of the form POST is likely related to avoiding "page contains both secure and non-secure items" messages from the browser and/or ensuring the parent.handleLogin() function or equivalent can be called. (I can't easily find information on how JS calls from a secure page to a non-secure page work.) –  dgw Oct 12 '10 at 23:15
    
@dgw THE PROVIDED LINK DOES NOT WORK ANYMORE. Sry for shouting - just to notify later readers. One of the reasons why links shouldn't be the answer. Please always add the content of links to your question. –  kaiser Dec 1 '12 at 17:45
    
Later readers will find that the link doesn't work any more on their own, won't they? I'm not convinced the shouting was necessary. Looks like a temporary error anyway. –  dgw Dec 1 '12 at 23:03

WordPress dieffrence for hhtp and https and when you call the AJAX with the default functions of WP than is a AJAX regsitration form possible. Maybe you see the plugin form from this tutorial: http://www.wpajax.com/code/ I think this is the solution for you.

share|improve this answer
    
Wow, that presentation was incredibly helpful and thorough... Still, it didn't help me solve my problem. What do you mean about the difference between http and https? Where is the problem coming up? –  goldenapples Oct 16 '10 at 19:35

Haven't looked at the plugin, but my guess is it's hard-coding the login URL without https in the Ajax request. The wp login form works fine in its non https version along with a form action that is set to use https, so I really can't see why Ajax wouldn't work.

If changing the plugin is not an option, you could try these approaches:

One would be some jquery goodness on the wp_footer hook. Search for the login form's ID and change it's URL, eg: $(ID).attr('action', newValue);

(I'm not 100 it'll work, though, as I vaguely recall jquery coughing on form tags when changing a form's method or action.)

A second approach, if the URL appears in the login form's HTML but not in its Ajax call, would be to start an output buffer on wp_head, and str_replace() the URL.

A third approach, if the actual url appears in the js script as a parameter, is to override it's value in wp_footer, as is done in the auto-thickbox plugin for the image urls used in wp.

A last option, if the script is messy spaghetti code with the login URL hard-coded within function calls, is to dequeue it using wp_dequeue_script(), and enqueue your own version to replace it. Mind priorities if you do this: your wp_print_scripts action should, obviously, occur after that of the plugin.

share|improve this answer
    
Sorry, I know this question is a bit outside the scope of this site... but thats why I bountied it. And I'm not stuck on using any specific plugin, its just that out of all the Ajax login plugins I looked at, this one seemed to be the most developed and should need the least work to get to where I needed it. Here are some details: –  goldenapples Oct 11 '10 at 19:45
    
The form action is set by site_url('wp-login.php', 'login_post'), and the Ajax submit is extracted from the form's action after calling event.preventDefault(); So both of those are pointing to https urls when FORCE_SSL_ADMIN is turned on. So the url of the form action is not the problem. –  goldenapples Oct 11 '10 at 19:49
    
Mm... In that case your frame approach is probably correct. I'd guess you're running into issues related to the browser security model, aka WP is trying to set a secure cookie on a non-secure domain, in other words a cookie within a page, with a different scheme/domain (not to mention path, since it gets set for wp-admin). –  Denis de Bernardy Oct 11 '10 at 21:46
2  
Btw, have you tried toying with the cookie domains and the admin cookie path defines (see the wp-settings.php file)? If the browser's security model is the issue, those might help by forcing them all to the site's root path. (At the obvious cost in security.) –  Denis de Bernardy Oct 11 '10 at 21:49

I've had a similar problem, and it turned out all depended on how the function wp_signon( $credentials, $secure_cookie ) was called.

I want everything on my site to be https after signing on, so a non-secure cookie is of nu use.

In my code from before ssl was: wp_signon( $credentials, false )

so I changed:

wp_signon( $credentials, false )

to

wp_signon( $credentials, true )

Which creates a secure cookie and now everything's fine.

I can imagine that plugin developers try to rely on FORCE_SSL_ADMIN to set the secure cookie, try using wp_signon( $credentials, false ) in your case. I hope it solves the problem.

share|improve this answer
    
Hmmm... that could very well be my problem. I'll try it out and report back. Thanks! –  goldenapples Jan 28 '11 at 22:25
    
@goldenapples So: How is it going? –  kaiser Feb 24 '12 at 10:59
1  
@kaiser Ha. I gave up on trying to do the Ajax login, it seemed like an unnecessary complication. Just provided a link to the login page over HTTPS. I guess I should try out some more of the suggestions here, though, so I can at least accept an answer here for other people. Will get back to this. –  goldenapples Feb 24 '12 at 20:12
    
@goldenapples Have you tried my solution here? I am using it for years without problems ... –  Tobias Beuving May 3 at 12:34

I had a similar problem with an AJAX plugin.

After a suggestion on http://stackoverflow.com/questions/6301076/wordpress-single-page-ssl , added this to the wp-config.php file:

if( !empty($_SERVER['HTTPS']) ) {
define( 'WP_SITEURL', 'https://yourdomain.com' );
define( 'WP_HOME', 'https://yourdomain.com' );
}

Then, I forced the specific page (with the AJAX thing) to be https:// only (there are plugins for that).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.