11 March 2009, 13:10

Some of you may find this useful if you want to use SSL / HTTPS:

If you protect the entire site using HTTPS IE starts issuing warnings about "secure and non secure items on the page" as soon as someone links to an off site non https resource

If you protect just the login page with HTTPS using Apache config you get the same warnings, as the style sheets etc are all referenced  as HTTP

You can get around the above problem by modifying config.php:

if ($_SERVER["REQUEST_URI"] == "/"){
    $cfg->wwwroot = 'https://mahara.org/';
} else {
    $cfg->wwwroot = 'http://mahara.org/';
}

So, if we are looking at the home page the wwwroot is https and therefore all links to style sheets coming off it are also https... thus no more nagging from IE.

The problem is that once logged in all the links are pointing to an https page, so, the next page you load, for example /group/mygroups.php will also be opened as HTTPS, and it is not until you click a link on that second page that you break back into HTTP... so... IE starts nagging you here instead...

So, in Apache (someone wiser than I) added the following:

First, set the home page to SSL / HTTPS:

RewriteEngine on
RewriteRule ^/$ https://%{SERVER_NAME}/ [R,L]

Secondly, in the SSL part of the config, this was added to force any pages that were not home to revert to HTTP:

RewriteEngine on
RewriteRule ^/(.+)$ http://%{SERVER_NAME}/$1 [R,L]

So... we finally managed to protect just the login routine without IE nagging us about secure / non secure items on the page...

Regards, Jez

11 March 2009, 18:11

Hi - I think I might have pointed this out before, but that doesn't protect the 'session timed out please log in again' page

11 March 2009, 20:37

Well, lets just say I have not seen you point that out before

In fact, i have never seen the session timeout, what is the URL it referst to?

Thanks, Jez

11 March 2009, 22:19

The session timeout login page can be shown at any URL, it's a 'transient' page in that respect.

If you set the session_timeout in the database down to, say '5' (5 seconds), then log out and in again, you'll see what I mean.

I think a true login-over-SSL solution is going to require a patch to Mahara, although if you never have session timeouts then you can get away with using apache rewrites.

12 March 2009, 3:45

I started a patch several weeks ago, but work load and procrastination in my spare time have stalled it

I'll try to bump it during the easter holiday.

Iñaki.

12 March 2009, 7:49

Yes it definitely need a patch then

The rewrites will have to do until Inaki finishes his work.

Thanks very much for producing this patch... it really is a bad plan to send LDAP SSO passwords in plain text... particularly if you have for example someone with access to finance systems logging Mahara.... which is quite conceivable.

29 March 2009, 12:02

It's been and interesting exercise (though Nigel helped me a bit, putting me in the right track ), but here are the patches (for 1.0.x, 1.1.x and master).

They use a new optional setting ($cfg->httpswwwroot) and should deal with transient logins (session timeouts) just fine.

The only thing that's missing (afaict) is protecting the password change page (account settings page). Things get complicated with the javascript interaction between encrypted and non-encrypted traffic and I don't master javascript/json/etc. at all, so I've given up by now . The patches are available at

• (1.0.x) http://git.eteo.mondragon.edu/gitweb?p=mahara.git;a=commit;h=6f87005a42e567e4f5034a158e02beb82d818625
• (1.1.x) http://git.eteo.mondragon.edu/gitweb?p=mahara.git;a=commit;h=c44979f6e17d516b18e4690f298cf9546707d1b7 
• (master) http://git.eteo.mondragon.edu/gitweb?p=mahara.git;a=commit;h=384d06e05fea57b6fcd098876f0da674dc4dfa17

If somebody could test them and verify that I didn't miss anything obvious, maybe they could be added to core.

Saludos. Iñaki.

29 March 2009, 16:47

I typed out a reply to this, but my laptop battery died

Next time you're on irc, we can talk about it.

One note now though - I don't know whether we've actually announced this anywhere, but we're only doing security updates for 1.0.X now. It's still supported for security issues and major regressions for a while, but we won't be putting any new features in to it.

29 March 2009, 17:43

Regarding the 'no new features in 1.0.x', it's OK with me. Backporting the patch from master was a 30 seconds work with git (git cherry-pick master-commit-hash), so I did it just in case someone with a 1.0.x setup is insterested in it.

Keeping the patch updated when security fixes are made is a zero-effort task  with git, so if there is demand for it, I could maintain it

Iñaki.

18 August 2009, 7:14