As the beta draws closer (it should have been released last week but we had to add some last minute stuff to avoid waiting 6 months before being able to integrate them), we just happened to organise the January Drupal Perú reunion here in Lima, and… well, let’s say we got a bit crazy and considerably extended the possibilities of the Drupal-Dokeos module, but got blocked by security issues regarding access to specific users’ data inside the portal.
So we thought that a user should, really, have a proper API key in order to let his Drupal portal access his own data and complete his account details.
The problem that appeared was that we didn’t really know what an API key should be… in the end, after discussing it for a while and looking around at the current offering, we decided that an MD5 string built randomly wasn’t too bad for a start, and I’ve taken the responsibility to add a new user_api_key table into the Dokeos main database to be able to store these keys, for users who want to generate one (and only them). Offering the possibility for one user to generate or delete a key improves the security and allow us not to bother people with a lengthy upgrade procedures (which would have to generate the MD5 strings for every single user, thus also using at least 32 bytes * the number of users of disk space). Another field, of type char(10), has been added to qualify the API key, for example in the case it’s actually an external API key (like to access Picasa, Hi5, LinkedIn or Facebook by using ‘picasa’,’hi5′, etc in this field). This could later be used by Dokeos plugins to implement specific features that connect to these external sites.
I could have used the new extra_user_fields stuff, but it seemed to me like a whole lot more complicated to deal with because of the visibility features of these fields.
Anyway, the table is in there, and there are a bunch of functions in main/inc/lib/usermanager.lib.php, but there’s still no interface (might be added in the beta).