We recently upgraded our Moodle 1.9 clients to Moodle 2.1. One of our clients also uses Wordpress with their students as a portfolio platform. As part of the upgrade, the client wanted us to develop a Single Sign-On solution between Moodle and Wordpress where the students on Moodle just need to click a link and they will be automatically logged in to their Wordpress subsite. Moodle would be the authentication authority so automatic account creation on the Wordpress side is also a requirement if no corresponding account exists yet on Wordpress.
We've done several SSO implementations before on Moodle 1.9 based on Moodle's MNET. But MNET will soon to be discontinued so we needed another solution that will be easily supported by Moodle. I've read that Moodle 2 is going to take the OAuth route but that it's not ready yet. Therefore I decided to write a basic OAuth server implementation for Moodle 2 and a corresponding OAuth consumer client for Wordpress. Hopefully, when Moodle 2's OAuth replacement for MNET is mature enough, the scripts to move our clients to this implementation are easy enough to create.
One of our other clients was using the Moodle 1.9 MNET implementation to SSO with Elgg. I was able to code an Elgg OAuth consumer plugin as well which is able to communicate with the same Moodle OAuth server so this allowed us to upgrade all of our Moodle 1.9 installs to the newer Moodle 2.1 and still retain the SSO functionality to different platforms that they require.
I've provided a tarball of the code implementation here in case this sort of implementation is useful to you. This includes the Moodle 2 OAuth server plugin, the consumer client plugin for Elgg 1.7 and the consumer client plugin for Wordpress. The wordpress plugin has been tested and runs on Wordpress 3.0.5 but the code is straightforward enough that it might work without modifications on later Wordpress versions. If you want to SSO to another platform but still want to use Moodle 2 as your identity provider then you can still use the server implementation of this code and write your own consumer client implementation.
For the past couple of weeks, I've used some of my time to write code that adds support for Federated Login for Google Account Users to an Elgg instance. This particular project's requirements don't end with just an implementation of Single Sign-On (SSO) but it also needs to have access to some of the user's Google Apps Data. Because of this, I decided to use Google's OpenID+OAuth Hybrid protocol, which is a good fit for the requirements.
The first thing I did was to register the domain of the application I'm writing with Google. You can read instructions on how to do this here. After I've validated the domain, I now need to write the interface to Google's OpenID+OAuth Hybrid protocol. The goal is to have SSO working with the capability to automatically create users on the Elgg side and map them to the proper Google account and to be able to request access to Google services.
I searched the plugins page for Elgg if anyone already wrote such a module and I got two results that piqued my interest. These are Kevin Jardine's OpenID client plugin and Justin Richer's OAuth plugin.
We were recently tasked with an Elgg project that requires forum discussions to behave like mailing lists. There's already a community contributed plugin that does something similar but doesn't quite meet the client's required specifications, notably with regards to permissions.
During the initial design, the client mentioned that we should think about reusability since the system might require other functionality that makes use of incoming emails in the future. So instead of just coding a plugin that will take care of discussions via email I decided to write a plugin that can handle incoming emails in a generic way and then trigger plugin hooks. The different plugins will then be responsible for implementation on how to handle the incoming email.
We recently posted about our project that implements Single Sign-On between Moodle and Elgg using Moodle Network (MNET). We wrote an Elgg plugin that extends the mnet-lib PHP library as part of this implementation. This early version of the plugin allows Elgg to function as an Identity Provider (IdP) so that its users can SSO to moodle. The current implementation assumes that ELGG is the authorative system. It doesn't have the capability to act as Service Provider. We expect to be doing a great deal more work to extend this plugin in its early stages so stay tuned!
About two weeks ago, a client raised an issue with their moodle installation. The client wanted course teachers to be able to take LAMS activites instead of just being allowed to author them. Then just this week, another client wanted to suppress the emails sent to course teachers when a student answers a quiz activity in moodle.
Both these issues are related in a way since the code logic that determines who can take a LAMS activity and the code for who are notified of quiz submissions both rely on checking moodle roles and capabilities. If you're familiar with moodle, then you'd be aware of the different roles that can be assigned to a user both on the site level and on the course level. What some people miss is that there are capabilities as well that's assigned to each of these roles. In order to resolve the issues that the clients raised without modifying the code, I needed to override these role capabilities so that they would behave as to how the client wants them to.
I'll outline here the steps of what you need to do to change the default roles capabilities in case you are faced with a similar problem.
To change the top-level role capabilities:
Solution Grove is in the process of testing an installation of the XO School Server (XS) of the OLPC project. Since I don't have an XO laptop, I needed to emulate one. I'm already running several virtual machines using VirtualBox so it makes sense that I go that route for an emulated XO.
I've outlined below the steps I did to emulate XO on VirtualBox. The steps here will most likely work with VMWare as well just by changing VirtualBox specific steps to their VMWare counterparts. These were researched and accumulated on the wiki.laptop.org and sugarlabs.org wiki pages. Some parts are copied verbatim and attribution go to their original authors.
In an earlier post, I wrote about how to properly integrate Adaptive Curriculum Activity Objects inside Moodle. After having success with that, the client now needs to have the activity object as part of a LAMS sequence.
The approach I came up with is to have the URL to the scorm activity created as a resource in the LAMS sequence. This particular client's LAMS server is in a different domain and port than the Moodle server and it doesn't satisfy the requirements of JavaScript's Same Origin Policy. This restriction presents a minor issue when launching the resource in a framed LAMS window. The only way to integrate it properly within LAMS is to have it launch in its window.
Solution Grove has a client who wanted to try out Adaptive Curriculum's (AC) Activity Objects (AO) inside Moodle. This initially sounded trivial since they provide SCORM compliant packages and I thought it was easy as just creating a SCORM activity for the AO. It turned out that AC's AOs are not standalone and they require authentication when installed on third party servers. Their objects use standard SCORM API calls for getting the user and session information then use these values to authenticate. The first part's the easy one since I don't need to write any code for that because Moodle already has API for SCORM 1.2.
The problem I encountered was that the authentication method used by AC needs to be run in a stateless manner through a server-to-server HTTP post using the user and session information that originated from the third party server (in this case, the moodle installation). This presents a problem for server-to-server communication because in moodle, the session id for the user is stored in a cookie and we will only be able to get that cookie if the script is run in the browser where it was issued. At this point, we are now in contact with AC to ask a few questions so that I can proceed implementing a code to support their AOs.
In order for us to track a one-to-one relationship between a Moodle course and an Elgg community we first need to create a mapping table. The table definition I used is as follows:
The eportid column corresponds to the Elgg community id for a particular course; the courseid is the one that tracks the Moodle course.<TABLE NAME="block_eportfolio_course_map" COMMENT=""> <FIELDS> <FIELD NAME="id" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" SEQUENCE="true" ENUM="false" NEXT="courseid"/> <FIELD NAME="courseid" TYPE="int" LENGTH="10" NOTNULL="true" UNSIGNED="true" DEFAULT="0" SEQUENCE="false" ENUM="false" PREVIOUS="id" NEXT="eportid"/> <FIELD NAME="eportid" TYPE="char" LENGTH="128" NOTNULL="true" SEQUENCE="false" ENUM="false" PREVIOUS="courseid"/> </FIELDS> <KEYS> <KEY NAME="primary" TYPE="primary" FIELDS="id" COMMENT="Primary key for block_eportfolio_course_map" NEXT="courseid"/> <KEY NAME="courseid" TYPE="foreign" FIELDS="courseid" REFTABLE="course" REFFIELDS="id" NEXT="courseid_uniq" PREVIOUS="primary"/> <KEY NAME="courseid_uniq" TYPE="uniq" FIELDS="courseid" PREVIOUS="courseid"/> </KEYS> </TABLE>
Since our code already supports single sign-on, we just add to that to track whether an Elgg community needs to be created. Let us reuse the signupredirect.php page and just add an extra variable that tells the system to create a corresponding community. The significant section is as follows:
The end result is a custom e-portfolio block that presents the following user experience:
As part of Solution Grove Blog's facelift, we added links to "share" the content to different social web communities. We already have the standard "Digg" and "del.icio.us" links in most of our client sites and we initially thought of putting this in our own blog. However, while browsing other blogs, I came across a niftier implementation. It's a free script provided by ShareThis. All you have to do is 1) register, 2) customize your "Share This" link using their "button builder", and 3) copy the code to your page or site template.
A few weeks ago, I posted how Solution Grove implemented Moodle to ELGG Single Sign-On. That was only the first phase. The client also needed it to seamlessly auto-create users on ELGG using credentials from the user's Moodle account. We searched for a solution for this and found his ELGG-WebCT integration solution from Aperto Elearning Solutions. Even though the other component was WebCT, it was still interesting to us as the concept is similar - the user is automatically created on the ELGG side. Solution Grove emailed Aperto and their contact person was kind enough to point to us the Aperto download server, where the code can be downloaded, and added a few tips in the email as well.
The assumption is that Moodle and ELGG were already properly installed and is confirmed to be working.
Here are the steps:
Subscribe to notificaitons