Hi all,
Using Moodle 2.3
I want to use https in few pages of my site, But when I use rewrite rules for certain pages, then the rendering of the pages in the browser is not proper.
May be this is the issue because some of the pages which I call through HTTPS there are some links on the page which are calling using HTTP.
So how can I handle this, so that I am able to use HTTPS on selected pages on my site.
Any help will be appreciated.
Thanks.
Hi Andrea,
Thanks for your reply.
But as you say if I make changes in $CFG->wwwroot = http://mydomain.id to
$CFG->wwwroot = https://mydomain.id , It will turn whole site into https and this really do not fulfill my requirement.
I want to apply HTTPS on selective pages, But Chrome blocked the css and the javascript files for those pages, as these are called through HTTP.
How can I call all the javascript and css files required for the page, in the moodle, seperately using HTTPS.
Thanks..
I don't think anyone is following what he is saying. I am running into the exact problem with my Moodle installations.
The affected portals are set to "HTTPS" logins only.
They are behind a load balancer so $CFG->sslproxy = 1; must be specified in the config file.
As a result of setting sslproxy=1 moodle expects the wwwroot to be https. If you aren't running an entire site as https you cannot do this so you have to apply a hack found by other users to bypass this check.
To bypass the check you have to comment out ~ lines 822-828 in wwwroot/lib/setuplib.php
// $CFG->sslproxy specifies if external SSL appliance is used
// (That is, the Moodle server uses http, with an external box translating everything to https).
if (empty($CFG->sslproxy)) {
if ($rurl['scheme'] === 'http' and $wwwroot['scheme'] === 'https') {
print_error('sslonlyaccess', 'error');
}
} /*else {
if ($wwwroot['scheme'] !== 'https') {
throw new coding_exception('Must use https address in wwwroot when ssl proxy enabled!');
}
$rurl['scheme'] = 'https'; // make moodle believe it runs on https, squid or something else it doing it
}
*/
If you google around for HTTPS login redirect, or login loop you will find other conversations / issues in the issue tracker.
The above fix combined with the sslproxy setting fixes the login loop problem for a setup behind a loadbalancer using SSL offloading.
Hi
I want my moodle site to not prompt certificate error(it has self-signed certificate). So, i have disabled ssl for this moodle site. But it still shows me the promt in IE (not in chrome though) even after changing the config.php file wwwroot from https://... to http:// .
Whereelse should I be changing settings in order for the prompt to disasppear?
Why not just get a real certificate? They are pretty cheap at https://www.ssls.com/
Or you might be able to get one free at https://www.startssl.com if your site meets their criteria for a free certificate.
I'm having this exact problem as well. I have fixed the HTTPS login loop issue with sslproxy=1 in the config and commenting out the section in setuplib.php.
My login page displays as HTTPS just fine but other random pages within moodle are displayed as HTTPS even though the entire site is set to HTTP.
If you go to site administration -> users -> accounts -> browse list of users and type in any name in the search field. When you hit submit Moodle redirects you to a HTTPS page and breaks the theme on certain browsers (chrome).
Chrome will not display non secure items on a "secure" page resulting in the theme being completely broken down (seen below).
'
I have yet to find a fix to this problem aside from setting the entire site to HTTPS.
Has anyone else found a solution or ran into this problem?
Do you have purchased valid SSL cetificate?
It seems self signed ceritificate or something...
The certificate is a valid certificate and is not self signed.
I have found multiple fixes for this issue. We have our Moodle site sitting in a load balanced environment with SSL offloading.
I was running into the same problem as you with HTTPS logins only and certain pages being rewritten as HTTPS which resulted in broken pages.
Here are the fixes we have implemented in our environment to workaround these issues. I would test them with your environment prior to putting them on a production site. This is with Moodle 2.4.7 but I would imagine it applies to more than one version.
1. Set sslproxy=true in config.php file
2. Comment out the following section from /lib/setuplib.php. Approximately line 822 - 828
3. Add the following lines to lib/pagelib.php typically found around line 1352
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] == 'https') {
$_SERVER['HTTPS'] = 'On';
return;
} else {
redirect($this->_url);
}
Use the image below as a guide. You will replace out the return; line with the enclosed code.
4. To prevent form pages from being rewritten as HTTPS you will need to comment out the following lines around line 175 in /lib/formslib.php
/*if (!empty($CFG->sslproxy)) {
// return only https links when using SSL proxy
$action = preg_replace('/^http:/', 'https:', $action, 1);
}*/
Hi, we are using v.3.0 and your method of setting ssl=true and apply your code hacks did not seem to work for us. Do you happen have updated code for version 3.0? We are working on plan to move to all https but in meantime, looking for fix..... thanks in advance ....
No hacks required.
1 Change your wwwroot in config,php to https (e.g. $CFG->wwwroot = 'https://yoursite.com';
2 Add/append to a .htaccess file in the Moodle root directory:
https:// redirect.
RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://www.yoursite.com/$1 [R,L]
Thanks ... but I want to redirect to http not https.
I've tried various versions of apache rewrite rules and cannot get it to work.
Think you kinda piggy-backed on a conversation that sounded like your problem, but isn't - maybe. Fist poster in this thread wanted https on certain pages in Moodle. Discussion then moved to a load balanced setup where certain pages (internal) were http and then to hacks of code - which, as you say, aren't working for ya. In your situation (depending on what that is) you may not need hacks.
So what is your setup ... load balanced? Single RH Apache box in front with backended dedicated DB server?
Your site does load and display just fine with http:// and with https:// for login only turned on it does flip to https:// just for the login with a valid cert ... and changes back to http:// (tested with guest login)
Google links to your site, however, present one with https:// which shows the wonky version.
Site does say y'all (pardon me, am in Texas, eh!) are going to be down/maintenance etc. coming up.
In RedHat apache config (httpd.conf) one could setup a redirect there (no htaccess but a true re-write rule forcing all traffic to https. Right now, would think that needs to be done when the upgrade is made to the site ... since it's gonna be down for upgrade.
And, if switching everything to https ... you'll have to turn off the https for login only, change the URL in config.php AND run the search and replace tool for any internal links that are now in the DB of the site for http://yoursite/somestuff/image.png - as an example.
Not sure there is any recommended order in which to take the site from https on login only to https and upgrade but you might consider first flipping the entire site to https first. Doing the search and replace ... checking things out to assure they work as expected under https. Then do the upgrade.
Of course, I could have the whole thing wrong. Mind explaining a little more ... or for others who might follow your path/issue, start a new discussion thread. ;)
'spirit of sharing', Ken
Thanks Ken. I've been reading tons of articles and moodle posts on the issue I have been having ... and I thought this one was relevant however I could be wrong. Our problem is simple, one that many others have as well.
We will be putting into production very soon, a new load balanced setup using gluster and F5 with dedicated memcache server and DB server. I will likely post our configuration in hardware forum for feedback - so far so good with testing though
However, for the interim I am just testing the rewrite in apache using a single web server (separate DB backend) (Apache, MySQL)
We have a valid certificate.
We run our moodle over http using https for login only.
If a user types in https:// css breaks and some scripts don't run. I know this is very common and the general consensus is to move to all https and do a database search and replace from http to https but I was just looking for a quick fix to keep everything http for the time being and try to redirect anyone who manually types in https to http.
Seems more difficult than I thought. Followed some suggestions here http://stackoverflow.com/questions/8371/how-do-you-redirect-https-to-http
I might be missing something simple or I might be trying to fit a square peg into a round hole....
ahhhhh!!! I got it finally. I can now redirect https to http successfully but I get a loop error on login. Sometimes I wonder if I should have spent this time simply configuring for all https! lol
Yes, if you're going to force it to http using rewrite rules, you have to use RewriteCond to exclude the login URL's.
Responding to this one ... but see your latest post says ya go it.
Two things:
"However, for the interim I am just testing the rewrite in apache using a single web server (separate DB backend) (Apache, MySQL)"
AND
"valid Certificate" (is that for this test setup?) Would think it might be useful to have a certificate for the domain rather than for a specific server. A domain cert is more expensive but whomever is the administrator for the certs can gen one up for any server that's going to be setup in the same domain. Just a thought. Would come in handy when setting up a test ... such as yours.
I do this often ... use same server or another physical server (has a different IP address) and configure the test setup with a virtual apache using the same FQDN as production. I then use local machines host file to make an entry that associates the IP address of the test setup with the FQDN that will be used. All machines handle DNS lookups the same way ... they check the local host file for references first before using actual DNS. Only those that know the mapping of IP hostname and who can edit their host file are the only ones who will be accessing the 'stealth' setup. Apache, if configured to serve out a virtual will do any domain ... even those that are NOT in any DNS.
Can develop all you like using the true FQDN of the production server ... remember all those internal URL's use wwwroot variable and are saved to DB.
The other ... longer way ... is to have two DB's for the 'stealth' box ... they match the wwwroot value as far as data then ... example: server non https uses nonDBname .... server configured to use https in config ... two changes ... the wwwroot + DB to the sslDBname. The trick is to get both DB's with current info AND https or not which could be done via dump, sed edit, import into other.
This may/may not work for ya ... it's a thought, however. ;)
'spirit of sharing', Ken
Is there a specific reason you don't want to run the whole site under HTTPS? When you run only login pages on HTTPS, but the rest of the site is on HTTP, this doesn't protect you from theft of cookies - meaning people can steal other peoples sessions on wifi (for example).
I would highly suggest keeping the whole site HTTPS at all times. There are no downsides and it is well supported.
We are going to switch to https very soon I think, but first we need to configure https on our test server, run search and replace, and do some testing. The last time I tested full https some of our scorm sites broke.
I was really just looking for a quick fix for the interim....
The apache rewrite seems to work fine on our regular test instance which is one web server but the same rule does not work on our load balanced F5. Something in F5 config is now interfering.
Hi James,
Question for you - how does caching in Moodle change when moving to all https? We currently use memcache server for application cache. We are using http with https over login only but considering a change to all https soon. Do you happen to know how this might be affected by the change?
TIA!!!!
Memcache, if used for Sessions or for MUC, communicates directly with Moodle itself. It's outside the SSL/TLS layer established by the webserver and the client - and thus works exactly the same weather SSL is enabled site-wide or not.
Oooops, sorry, misread the issue
