When loading a page that requires the user to be logged in, eg /account, the login form presented will not work if SSL is forced for wp-admin because the function call that gets the AJAX URL returns an https:// version of the URL, despite the document request being http://.
Steps to reproduce:
• Force SSL for wp-admin eg by defining FORCE_SSL_ADMIN true†
• From a fresh incognito browsing session, visit http://domain.com/account (or whatever it is on your local installation)
• Log in with valid credentials
=> Login form reloads as if nothing happened.
† It may or may not be relevant, but we also use WPMUdev's domain mapping plugin, and I know that the admin_url function gets messed with, though I thought that issue had been fixed.
• Now visit https://domain.com/account
• Try to log in again
=> It works fine.
The reason the former case doesn't work is because the AJAX login request is to an HTTPS URL but from an HTTP page. The AJAX request comes back with valid cookies, but for whatever reason, the browser will not store them. I'm not quite sure why, but I've seen this same problem with mixed http/https before. Though the situation is slightly different (in our case, there isn't a domain/CN mismatch issue because we store the M2P pages on the original domain), the mixed protocol issue is the same and the conclusion to that support case might give a clue as to what's going on.
There are at least two work-arounds for this:
• redirect M2P pages to https might work (but may conflict with Domain Mapping depending on how DM is configured),
• wrap the account form in [ms-user] tags (see an example) and use the traditional /wp-login.php mechanism.