Elxis CMS Forum
Support => Administration => Topic started by: gmelis on July 13, 2012, 12:48:48
-
I was trying to force SSL only for the admin login page, everything else should be plain http. So, after some experimenting I found this to work as expected (as long as you have SSL support for your site):
Open the .htaccess file in the root folder of your site and add these lines at the end:
RewriteCond %{HTTPS} =off
RewriteCond %{REQUEST_URI} .*/administrator/.*
RewriteCond %{REQUEST_URI} !.*/administrator/index[2-9].php.*
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{HTTPS} =on
RewriteCond %{REQUEST_URI} .*/administrator/index[2-9].php.*
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
Then, in the same file find the line that says:
RewriteRule ^(administrator/|bridges/|cache/|components/|editor/|help/|images/|includes/|language/|mambots/|media/|modules/|templates/|tmpr/) - [L]
and delete the "administrator", so it's like this:
RewriteRule ^(bridges/|cache/|components/|editor/|help/|images/|includes/|language/|mambots/|media/|modules/|templates/|tmpr/) - [L]
There, you're done.
In another twist, you can also use this in a reverse proxy scenario, where you don't want to be changing all these htaccess files. In that case, all you have to do is add the lines
RewriteCond %{HTTPS} =off
RewriteCond %{REQUEST_URI} .*/administrator/.*
RewriteCond %{REQUEST_URI} !.*/administrator/index[2-9].php.*
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
RewriteCond %{HTTPS} =on
RewriteCond %{REQUEST_URI} .*/administrator/index[2-9].php.*
RewriteRule (.*) http://%{HTTP_HOST}%{REQUEST_URI}
at the configuration files of the reverse proxy and you're done. Of course, the reverse proxy must provide the ssl support.
-
Note
The rewrite rule you post does not cover the login page (index.php).
RewriteCond %{REQUEST_URI} .*/administrator/index[2-9].php.*
For Elxis 2009.3
You can do it without htaccess with a few lines in php.
if (!$mainframe->detectSSL()) {
$url = filter_input(INPUT_SERVER, 'REQUEST_URI', FILTER_SANITIZE_URL);
$url = $mainframe->secureURL($url, true);
mosRedirect($url);
}
Place the above code in index.php, index2.php and index3.php files located inside the administrator folder exactly bellow the $mainframe initialization.
$mainframe = new mosMainFrame( $database, $option, '..', true );
//place the code here....
If you want to force the redirection to the login page instead of any administration page then instead of this:
$url = filter_input(INPUT_SERVER, 'REQUEST_URI', FILTER_SANITIZE_URL);
use this:
$url = $mainframe->getCfg('live_site').'/administrator/';
EDIT: I thought it better, you will have problems with this script if you dont overwrite the "live_site" url with the secure one.
To fix this you need to a new line in index.php, index2.php and index3.php
Find:
require_once($elxis_root.'/configuration.php');
Add bellow:
$mosConfig_live_site = preg_replace('@^(http\:)@i', 'https:', $mosConfig_live_site);
For Elxis 4.x
Just enable SSL/TLS for the administration pages in Elxis configuration.
-
If you read more carefully, you'll see that the line you mention is in the part that says "now leave ssl mode". The idea is that I want to use https not for all the admin pages but only for the admin login page; once you login, you're back to http.
You see, my problems were (are) that (a) I don't know php, (b) I want *only* the login page in ssl and (c) messing with the per site stuff would place a burden on me that wouldn't be welcome.
Of course (a) is my problem, but (b) and (c) are very legitimate reasons for the htaccess changes. Let me give you this scenario:
A reverse proxy that serves tens of sites, and connects to them using http. Thus you have two connections, con_a from the client to the reverse proxy and con_b from the reverse proxy to the elxis server. In such a scenario, where con_b is always http, if you turn on ssl in con_a you have a problem: Javascript is a bit picky about mixing http and https, and many things will not show up nicely, or even work at all; see what happens with tinymce when you mix http and https. So, the preferred scenario says that you turn on ssl in con_a during the login and turn back to plain http for the rest of the session.
And do that without toying with all those "customer" sites on a site to site basis, 'cause I can't touch them and I have no intention of burdening myself with all this pesky tinkering, and still provide them with the secure login they desire. And make this work with whatever admin page confusion schemes they might have already set up for thei sites (like "/administrator/mitsouklas")
Besides, tell me why meddling with three (3) index files instead of one htaccess file is better.
-
If you want to force SSL only in the login page then apply this patch only on index.php file...
My recommendation is to either force SSL in ALL admin pages or don't do it at all.
The EDIT section I wrote solves the javascript/css/images problem you mentioned (this is why I added it) because it re-writes an Elxis configuration variable ($mosConfig_live_site) making all absolute URLs SSL enabled.
Elxis constructs URLs, to images for example, by using the following pattern:
$mosConfig_live_site.'/xxx/yyy.png';
So if you make $mosConfig_live_site SSL enabled you solved the problem.
Note: $mosConfig_live_site is the same as $mainframe->getCfg('live_site')
-
Ok, so now we go into theoretical stuff. HTTP or HTTPS? Keepalive or not?
Making a connection fully https means two things: First is the SSL handshake overhead, and second session reuse. The SSL handshake has an overhead, cpu wise and thus power-consumption wise, for both the client and the server, of about 20% of a simple http connection. So, when entering https mode, you better keep your session open and reuse it for the rest of your communication, especially if you're using a battery powered device. How you do that? with keepalives. But keepalives mean more memory usage on the server side, i.e. the server has to keep the session open for the consecutive requests in https mode. On the other hand, if you do not keepalive your session, you have a new ssl handshake on every connection, and you don't want that: it's very slow and power consuming.
So, in my experience, the best practice is to ssl what you need too keep safe and let the rest go by unencrypted. Especially if ram comes at an expense.
Of course, if the aforementioned constraints are not applicable in the case at hand, you can SSL as much as you like.
As a last note, in the case of the reverse proxy serving many sites, the apache reconfiguration still seems to be a better idea.