[SOLVED] Shared SSL / Preventing HTTPS URL Rewriting (mod_rewrite)

With almost any web hosting company you are typically given access to a static URL were can access your site, test your website development, etc. This is generally nice for early development prior to DNS updates fully replicating (pointing domain.com -> webhost.com/~username)

Also, certain web hosting companies might even given access to a "shared" SSL certificate that resides on your hosting server.

Example of accessing a shared SSL cert on a shared hosting account URL

https://server123.webhost.com/~username/secure_file.html

Now, getting to business - Some clients might have a need to host a file via HTTPS, but might not want (or need) to fork out the cash for an SSL cert each year. So, having access to the shared SSL can be nice and also come in handy.

With the new .htaccess shipping in 0.9.6 RCx, you are given an option (one I ALWAYS use) to help force your preferred domain.
e.g. You can FORCE your site’s HTTP requests to ALWAYS or NEVER use www., etc.

...In this scenario, I am choosing to FORCE the ’www.’ (NOTE: I have hard-coded domain names on purpose)

Quote from: "Example

RewriteCond %{HTTP_HOST} !^www\.domain\.com [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

However, there is an unwanted side effect:

https://server123.webhost.com/~username/secure_file.html

inadvertently becomes

http://www.domain.com/secure_file.html

...unfortunately dropping our desired HTTPS protocol form the URL! That simply won’t do...

One solution could be choosing to ONLY force the preferred domain when the HTTP request contains your domain name, and not that of the hosting company/shared server:
Quote from: "Example

RewriteCond %{HTTP_HOST} !^server123\.webhost\.com [NC]
RewriteCond %{HTTP_HOST} !^www\.domain\.com [NC]
RewriteRule ^(.*)$ http://www.domain.com/$1 [R=301,L]

...this effectively checks if the HTTP_HOST in the URL request contains the shared server sub-domain/domain and does nothing if it does. Ultimately, your HTTPS:// resolves nicely, as intended.

NOTE: As long as there aren’t any issues with globally preventing "server123.webhost.com/~username" requests from rewriting to "www.domain.com" then you should be set. For some, there may be value in modifying this example to only prevent URL rewriting for specific, unique URLs.

Note also the Encryption snippet I added to the resources to enable encryption of pages using a shared certificate on a page-by-page basis.

Andy

The only issue with such a thing is that when going from unencrypted to encrypted the SESSION is started fresh, sometimes the original SESSION variables are still needed. There are (at least) four solutions to this:

1. Go to the encrypted site before collecting any important SESSION data

2. Write a plugin or snippet to transfer the data from one SESSION to the other (usually involves cookies or query string passing of original SESSION ID).

3. Don’t store the data in a SESSION, use the database or a flat-file and pass an ID as above.

4. Specify the original session name before starting the session on the encrypted pages.