Are you going to the Open Source Bridge conference in Portland in June? Hopefully I’ll see you there. I’ve submitted a proposal to talk about what we’re doing here at the OSL to support the Oregon Virtual School District.
Archive for the 'ORVSD' Category
Wow. I am amazed at how quickly teachers are latching onto the Oregon Virtual School District stuff.
Since I set up a system to automatically create school Moodle servers on demand, 109 Moodle instances have been spawned on the shared-code Moodle system. That means at least one teacher from 109 different public schools and ESDs in Oregon has been interested enough in the ORVSD offerings to give it a try. Of course, only a small number of them are far enough along to be using it with their students, but there are quite a few teachers getting up to speed with how the tools work. I’m delighted to see the system seems to be scaling up remarkably well. It’s not having any problem at all dealing with so many separate vhosts/databases running on the same Moodle install.
I expect we’re going to see an explosion of use by the end of the summer and beginning of next fall. I guess I better get those disk arrays ordered … we’re probably going to need a lot more disk space soon.
When I first started working with Moodle servers, one of the things that bugged me was the fact that it required a complete install of the code for every site hosted on the system. While that’s fine for most circumstances, it really did not work well in our environment where we’re looking at potentially hosting hundreds of Moodle instances. So, in the fine open source tradition of scratching an itch by finding something someone else has done, modifying it, and then sharing it with the world … I give you shared-code Moodle, OSL-style.
First, though, credit where credit is due. Martin Langhoff posted almost all of what we needed to do here. All I needed to do is expand upon it to fit our needs.
Second, what the modified code actually does:
1) config.php looks in Moodle dirroot/multisite_config for an ini file matching the server name. I.E.: fqdn.domain.org.ini
2) If found, the ini file is parsed and used to populate the Moodle $CFG
On to the code!
User name validation - a quick look at the Drupal API reveals exactly the function I needed: user_validate_name()
To add user name validation to the OpenID Drupal module, add the following code to the openid_create_account_submit() function immediately after the $query = $_POST; statement:
if (user_validate_name($query['edit']['fullname']) != NULL) {
$error = user_validate_name($query['edit']['fullname']);
drupal_set_message('Name is invalid. '.$error, 'error');
header("Location: " . url('openid/get_email'));
exit(0);
}
Worked like a charm. Any user name submitted when registering using an OpenID is now validated against Drupal’s internal user name validation - alphanumeric characters and spaces only. Anything else drops the user back to the name and email request form with an error telling them why the name was rejected. Slick!
Now I just need to figure out how to map existing Drupal users in the database to OpenIDs. Anyone done that before?
UPDATE: Resolved the above question. Add a record to the authmap table with the user’s UID and OpenID. Make sure the OpenID is normalized (has the trailing slash).
UPDATE #2: Updated the diff file that shows what I changed from the stock OpenID Drupal module.