Thanks for answering so quickly.
Question: Is being logged in on both http and htpps not a security thread?
Having admin access over htpp defeats the whole purpose of using SSL
I mean, when I am logged in over http WordPress has to send the normally secure session cookies with user credentials over http, which make them vulnerable for session highjacking. This is a thing I really not want to happen and that's why I use SSL
From what I know, when using the "FORCE_SSL_ADMIN" in wp-config.php WordPress uses secured cookies with user credentials only to be sent over SSL. And a "logged in" cookie used over http to chance links in the meta widget and to show the admin bar on normal pages pulled over http. When I click on a "Dashboard" link it's a https link. on the https connection the browser includes the secured cookies with credentials. When only the normal not secure "logged in" cookie is present and no secure cookies with user credentials are present WordPress and the https Dashboard link is clicked WordPress doesn't receive the secure credentials cookies and redirects to the login screen.
So secure login cookies are never send over http. And this never should be done when using Dashboard over SSL.
What I understand and please correct me if I am wrong, the new option will send cookies with user credential over both http and https. If this is the case, I think this is a really, really bad idea. It defeats the whole purpose using SSL in the first place...
If you are only sending the normal "logged in" cookie over the http it's OK. This is what wordpress default does when using the "FORCE_SSL_ADMIN" directive in wp-config.php
But this still leaves me with the CDN issue. I really like to have a way to connect directly with my server using the ssl.mydomain.com for both the Dashboard and the site it self. The Dashboard should run over https / SSL The site can be just be non secure http like the standard setup using the "FORCE_SSL_ADMIN" directive.
So implementing a rewriting option in this way only rewrite the normal links from mydomain.com to ssl.mydomain.com and leave http to http. The WP "logged in" cookies do work over the normal http connection, cause it's the same domain. And al functions well, admin bar, dashboard links etc.
So this method doesn't have to interfere with the "Force SSL Exclusively" option. That still can do it's job.
Which brings me to the consideration that your plugin is already great, but unfortunately lakes a other great feature, which would it make even more generic in using SSL over a alternative (sub)domain. If you would consider this extra option it would be really great.
Point is, options may be mutually exclusive, that's really no problem. Just state it clearly as you have don with the "FORCE_SSL_ADMIN" directive and "Force Shared SSL Admin" option.
It just makes a better plugin, that can be used in different fields.
Shared hosting environments with SSL on a different domain.
CDN setups that don't support SSL and let users access WordPress over a aliased domain to manage and view there sites, directly.
The viewing directly on the aliased domain bypassing the CDN is really important, to avoid looking at a outdated page cached by the CDN
Which brings me to my last point: A bug / unexpected behavior I ran into testing different options and combinations.
When I check the options: Shared SSL and
Force Shared SSL Admin (or use the "FORCE_SSL_ADMIN" directive instead of Force Shared SSL Admin) And I check "Force SSL Exclusively" It renders my site inaccessible, with the message: "Too many redirects." In Safari and in Firefox: "Firefox has detected that the server is redirecting the request for this address in a way that will never complete."
So these two functions are conflicting which each other anyway. I don't know if these functions where intended to work together or are in fact mutually exclusive , but they don't at this time. For me that's no problem as I wouldn't use this function anyway.
Thanks for working on this plugin and willing to answer user questions like mine.