larsenja

Hi, please forgive me if it is bad behavior to piggy back on an existing request, but I’ve noticed the same thing. In using TinyMCE Advanced, I can no longer embed videos.

I’ve discovered that 3.9.1 is stripping out all iFrame calls which is what TinyMCE Advanced utilizes when placing video embeds.

esmi, or anyone else – is there a way to restore this functionality so that the TinyMCE Advanced video embed will work again?

RESOLVED.

We ended up writing custom .htaccess rules in such a way that it would enforce https:// connections when necessary while allowing /wp-login requests to pass through when https:// isn’t needed.

This bypasses the need for FORCE_SSL_ while maintaining a secure backend.

I clearly am not explaining this properly. The pasword protected pages work great *if* we turn off FORCE_SSL_ADMIN / FORCE_SSL_LOGIN.

Likewise, password protected pages *also* work just fine with FORCE_ turned on
EXCEPT for the fact that it generates a “scary” message that the mapped domain is trying to use the SSL certficate of the underlying server. Firefox in its presentation of the error says “Get me out of here” and IE uses a double negative to essentially force people to close the connection rather than proceeding. All because the underlying certificate doesn’t match the mapped domain. (Which is standard browser security…)

In our case – this isn’t an issue of a custom password form within the template at all.
Everything is working as it should be. The problem is that by WordPress making this change it has created a conflict between mapped domains and the underlying server’s SSL certificate.

This was never a problem before because the /postpass.php function sat outside of the FORCE_SSL_ feature.

I need a way where the mapped domains can access /wp-login.php?action=postpass on an http connection while the underlying server’s login and backend are secured. I’ve tested all available plugins but they all essentially ride on top of the FORCE_SSL_ feature and so they don’t work. (WordPress HTTPS included.)

What I need is when the action of /wp-login.php?action=postpass is encountered it remaps the login so it would use the parlance of https://blog_name.protected_server.com/wp-login.php?action=postpass so that the request would ride on top of the wildcard certificate of the underlying server.

I had thought about using .htaccess to re-write the requests when it encounters them but the only way to make that work assumes the mapped domain matches the blog_name. When people have multiple domains pointing to the same place, this idea breaks down…

Any other suggestions on how to achieve the above goal are also welcome! Thanks!

Hi – thanks. I appreciate the help. I actually had seen that particular post before submitting this. My takeaway for what those folks wrote was that their templates were using custom coding that was hardcoded into the themes that called the login the “old” way which was rendering the login unusable.

The one bit of info that was “different” was what Teri wrote:

I spent a lot of time looking for a problem with our theme, but our issue turned out to be something entirely different. Maybe this post will help someone else.

If your setup runs SSL on the admin portion of your site, but the public-facing site is not secured, the password cookie isn’t being recognized. If you put the “s” in “http” on the page with the password and it works, you can solve this issue by rewriting the password form in your theme’s functions.php file like this:

However, the above is only useful for enforcing an https connection when the backend is via SSL and you want the front-end to also encode https.

Our situation is different in that we *don’t* want the password protected pages to trigger the https:// but where the backend login *is* secure. Does that make sense?

Thank you for the suggesting. Working backward one by one we discovered that the WordPress HTTPS plugin was causing this problem.

Has anyone had any success with https://updraftplus.com for multisite?

Great question. Looks like we are running PHP 5.2.17.

PHP Version: 5.2.17
PHP max_execution_time: 60 (seconds)
WordPress Version: 3.5.1
MySQL Version: 5.5.30
Zip Methods: exec, ziparchive, pclzip
PHP Register Globals disabled
PHP Magic Quotes GPC disabled
PHP Magic Quotes Runtime disabled
PHP Safe Mode disabled
Operating System: Linux