Van Patten Media

Designed to be run in concert with <a href="https://wordpress.org/extend/plugins/ssl-subdomain-for-multisite/" rel="ugc">SSL Subdomain for Multisite</a>.
This plugin depends upon <a href="https://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/" rel="ugc">WPMU Domain Mapping</a>, which must be installed and network activated for this to work.
<h4>What this Plugin does</h4>
If you have the <a href="https://wordpress.org/extend/plugins/ssl-subdomain-for-multisite/" rel="ugc">SSL Subdomain for Multisite</a> plugin installed and network activated, you now have logins and admin happening on <code>https://demo-site.mynetwork.com</code>, while normal site access is on <code>http://demo-site.com</code>.
This works great. Except, once you log in to <code>demo-site.mynetwork.com</code> to do some admin work, then visit the main site, perhaps to post a comment as a logged in WordPress user, you are not logged in on the main site. This means that you can’t, for example, post that comment while logged in — you aren’t logged in there! Other logged-in niceties like the display of the admin bar, or the avoidance of caching, are not available. If you log in again, it logs you in to <code>https://demo-site.mynetwork.com</code> but still you remain not logged in on <code>http://demo-site.com</code>.
This plugin solves this problem by enabling a single sign on (SSO) for both the admin panel and the main site on the custom domain. Upon login, this plugin bounces the user across to the main site to set a cookie there, then bounces them back to the admin panel.
Now, you can work in the admin panel normally, and if you click ‘Visit Site’ from the Admin panel, you go over to the custom domain, where you are also logged in and can perform all actions as normal. Single Sign On!
<h4>(Foolish) Assumptions</h4>
<ol>
<li>
You are using <a href="https://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/" rel="ugc">WPMU Domain Mapping</a> for custom domains on your Multisite network.
</li>
<li>
You have SSL configured for your master domain (e.g. <code>www.mynetwork.com</code>), and for the wildcard <code>*.mynetwork.com</code>. You would like normal site access to happen over the custom domains with HTTP, and all admin and login access over the subdomains of <code>*.mynetwork.com</code> with HTTPS.
</li>
<li>
You have the <code>FORCE_SSL_LOGIN</code> setting in <code>wp-config.php</code> ON.
</li>
<li>
You have the <code>FORCE_SSL_ADMIN</code> setting in <code>wp-config.php</code> OFF. We’ll handle that — WordPress’ forcing of SSL admins may confuse this plugin.
</li>
</ol>
This plugin was tested with and is intended to be used in concert with <a href="https://wordpress.org/extend/plugins/sso-cross-cookie-for-multisite/" rel="ugc">SSL Subdomain for Multisite</a>.
<h4>Known Issues</h4>
<ul>
<li>The <code>redirect_to</code> parameter is not fully working at present. Sometimes, you will be sent to the root admin page, instead of the specific page you were trying to access. This needs to be improved, as it does compromise the user experience.</li>
<li>
This provides better security than only enabling <code>FORCE_SSL_LOGIN</code> but not <code>FORCE_SSL_ADMIN</code>, since with this plugin and <a href="https://wordpress.org/extend/plugins/sso-cross-cookie-for-multisite/" rel="ugc">SSL Subdomain for Multisite</a>, login and admin are served over HTTPS.
However, the nature of this setup means that a man-in-the-middle attacker could theoretically impersonate you for the duration of the login session. It is not possible at the moment to avoid this theoretical attack scenario without serving everything over HTTPS (making arbitrary custom domain support impossible), or preventing login to the actual custom domain site.
</li>
</ul>

SSO Cross Cookie

Single sign on (SSO) for a custom domain site, where the admin panel is on an SSL-secured subdomain. For WordPress Multisite.

Ensures logins are always done via SSL on a subdomain of the master domain, but that access to custom domains are always done over HTTP, to avoid certificate errors. For WordPress Multisite.
WordPress’ built-in <code>FORCE_SSL_LOGIN</code> and <code>FORCE_SSL_ADMIN</code> directives in <code>wp-config.php</code> work great, but are too restrictive in situations where you have custom domains — custom domains for which you cannot have SSL certificates. For sites on custom domains, we need to make sure that the login and admin access happens over the subdomain, which can be properly served over HTTPS.
<h4>What this Plugin does (incorporating Foolish Assumptions)</h4>
or, a readme you should read before implementing this plugin on your site.
This plugin filters the login, logout, home and admin URLs that WordPress uses to generate its internal links.
Why do we do this?
<h4>The Scenario</h4>
We have a WordPress Multisite network. Let’s call it <code>mynetwork.com</code>. We bought a fancy SSL wildcard certificate so we can offer <code>*.mynetwork.com</code> over a secure connection.
We’d very much like to use this secure connection for all logins, and for all admin access.
We also allow sites on this network to use a custom domain — like <code>demo-site.com</code>. We might be using <a href="https://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/" rel="ugc">WPMU Domain Mapping</a> to achieve this. These sites have two domains, then — <code>demo-site.com</code> and <code>demo-site.mynetwork.com</code>.
If we switch on <code>FORCE_SSL_LOGIN</code> or <code>FORCE_SSL_ADMIN</code>, we have a problem. When users go to <code>https://demo-site.com/wp-login.php</code>, they get a certificate error. We have a wildcard certificate for <code>*.mynetwork.com</code>, but we can’t possibly have a valid SSL certificate installed for every custom domain!
Instead, we want to force all login pages and admin pages to be:
<pre><code>https://demo-site.mynetwork.com/wp-admin/… </code></pre>
We want all regular access to be:
<pre><code>http://demo-site.com/… </code></pre>
This plugin facilitates that — rewriting the <code>wp-login</code> (including logout) and <code>wp-admin</code> URLs to the first example, and rewriting all the others to the second style.
<h4>Foolish Assumptions</h4>
This plugin makes some (foolish) assumptions about your multisite network. You must make sure that these assumptions are true for your site, or you will find that this plugin may have unintended consequences and break things that are difficult to fix without manually disabling the plugin.
<ol>
<li>
Your subdomains are in the format: <code>a.b</code>
<blockquote>
where <code>a</code> is, for example: <code>demo-site</code>. <code>b</code> is, for example: <code>mynetwork.com</code>. <code>a</code> must be a single domain component. (<code>a</code> can’t be, for example: <code>demo.site</code>)
</blockquote>
</li>
<li>
Your wildcard certificate is configured properly for:
<ul>
<li><code>*.mynetwork.com</code></li>
<li>your network site URL</li>
</ul>
So if your network site URL is <code>www.mynetwork.com</code>, your wildcard cert will be fine. If it is just <code>mynetwork.com</code>, you will need another cert to avoid errors when you go to <code>https://mynetwork.com/wp-admin</code>.)
</li>
<li>
Your site already has the custom domains working.
<ul>
<li>
I suggest the excellent <a href="https://wordpress.org/extend/plugins/wordpress-mu-domain-mapping/" rel="ugc">WPMU Domain Mapping</a> for this.
<ul>
<li>Your web server also needs to be <a href="http://www.lampjunkie.com/2008/05/how-to-set-up-a-wildcard-catch-all-virtual-host-in-apache/" title="A tutorial on wildcard catch all hosting for Apache" rel="nofollow ugc">set up</a> to handle hosting a wildcard name virtual host. All of this is really part of the WPMU Domain Mapping set up, and not the set up for this plugin. I’m just, you know, mentioning it.</li>
</ul>
</li>
</ul>
</li>
<li>
You have the <code>FORCE_SSL_LOGIN</code> setting in <code>wp-config.php</code> true.
</li>
<li>
You have the <code>FORCE_SSL_ADMIN</code> setting in <code>wp-config.php</code> false. We’ll handle that — WordPress’ forcing of SSL admins will conflict with this plugin.
</li>
</ol>

SSL Subdomain for Multisite

Ensures logins are always done via SSL on a subdomain of the master domain, but access to custom domains are always over HTTP, to avoid cert errors.

SSO Cross Cookie vs SSL Subdomain for Multisite