I planted a seed and I continue to water the tree over many years but it's much bigger than me now.
Martin Dougiamas
Posts made by Martin Dougiamas
Hi Marc.
Enjoyable as it is, let's bring this conversation back to some facts ...
From what I can see this is a matter of one (possibly very old, I don't know) site that had email authentication on as well as profiles visible, allowing a spammer to add some public junk to a profile page. With those two settings off (or any one of them) it would not be possible.
No existing accounts were compromised and at no time was the existing information in the site stolen or threatened. Right? The information on the site was indeed secure as described in the excerpt you posted (I'm not trying to be picky, just accurate).
So if you're truly investigating this incident to look where improvements need to be made (and I'm not sure this forum is appropriate at all) it comes down to who was responsible for opening those settings.
Is it Moodle software? It's true in the more innocent past that the defaults for these were on, which could very well be the problem for this site. We relied on the admin to switch them off, but that is no longer the case in current versions of Moodle - they are off with big warnings attached. Some other troublesome defaults have been changed as well in reponse to community feedback in the tracker. This helps EVERYONE installing a new Moodle. So if the fault lies with Moodle software then it's largely been fixed since then, though I know we can do even more about usability and user education. Further development is underway regarding this, and more suggestions are always very welcome in the tracker.
Is it the hosting company? One could surely argue that they should provide new sites in the most locked-down configuration possible, which may not always be exactly the same as the default install configuration of a standard Moodle. Security is surely one important factor of a new installation, I think we can all agree, but I can also see that sometimes it's not always wise to force all clients to turn every feature on. That's really up to each individual company to implement with their clients, but I hope the companies I'm associated with (Moodle Partners) will always use feedback like yours to review their SLAs and procedures to further improve quality all around. You may want to call them directly and ask about it if you're interested. A willingness to improve such things is what makes Moodle partners different to your average schmoe selling server space because they just worked out how to use Cpanel (and there are many of these out there). Every time we issue new security fixes (such as the ones on the Moodle Security page http://moodle.org/security) these guys have to update many hundreds of sites (and boy do they love it
).
Is it the client? Well, no, the client is always right, of course. Luckily clients never change settings they don't understand properly and always read the context help and documentation (as far as we can tell). That makes our life so much easier.
Enjoyable as it is, let's bring this conversation back to some facts ...
From what I can see this is a matter of one (possibly very old, I don't know) site that had email authentication on as well as profiles visible, allowing a spammer to add some public junk to a profile page. With those two settings off (or any one of them) it would not be possible.
No existing accounts were compromised and at no time was the existing information in the site stolen or threatened. Right? The information on the site was indeed secure as described in the excerpt you posted (I'm not trying to be picky, just accurate).
So if you're truly investigating this incident to look where improvements need to be made (and I'm not sure this forum is appropriate at all) it comes down to who was responsible for opening those settings.
Is it Moodle software? It's true in the more innocent past that the defaults for these were on, which could very well be the problem for this site. We relied on the admin to switch them off, but that is no longer the case in current versions of Moodle - they are off with big warnings attached. Some other troublesome defaults have been changed as well in reponse to community feedback in the tracker. This helps EVERYONE installing a new Moodle. So if the fault lies with Moodle software then it's largely been fixed since then, though I know we can do even more about usability and user education. Further development is underway regarding this, and more suggestions are always very welcome in the tracker.
Is it the hosting company? One could surely argue that they should provide new sites in the most locked-down configuration possible, which may not always be exactly the same as the default install configuration of a standard Moodle. Security is surely one important factor of a new installation, I think we can all agree, but I can also see that sometimes it's not always wise to force all clients to turn every feature on. That's really up to each individual company to implement with their clients, but I hope the companies I'm associated with (Moodle Partners) will always use feedback like yours to review their SLAs and procedures to further improve quality all around. You may want to call them directly and ask about it if you're interested. A willingness to improve such things is what makes Moodle partners different to your average schmoe selling server space because they just worked out how to use Cpanel (and there are many of these out there). Every time we issue new security fixes (such as the ones on the Moodle Security page http://moodle.org/security) these guys have to update many hundreds of sites (and boy do they love it
Is it the client? Well, no, the client is always right, of course. Luckily clients never change settings they don't understand properly and always read the context help and documentation (as far as we can tell). That makes our life so much easier.
Yes AFAIK this works fine now (there *were* some bugs in earlier versions of Moodle)
Hmm ... something is wierd ... I'm not sure you have a correct copy of the code.
Alex can you go to
Admin > Server > Debugging
And turn "debug" level to DEBUG_DEVELOPER and make sure debugdisplay is on.
Then visit the forum again and see what errors you get. Please follow up in MDL-16925
Alex can you go to
Admin > Server > Debugging
And turn "debug" level to DEBUG_DEVELOPER and make sure debugdisplay is on.
Then visit the forum again and see what errors you get. Please follow up in MDL-16925
Thanks for reporting that, it looks like a bug caused when backporting MDL-14558 from 1.9. I've assigned someone to fix it and we'll redo the tagging for the 1.8.7 release later today.