We know Moodle and ILIAS from the inside.

1Typical projects

Plugins & extensions

New features that feel like part of the platform.

LTI integrations

Embed external tools or provide your application as an LTI tool.

Single sign-on

Shibboleth, SAML, OAuth2 or LDAP, matched to your identity provider.

Campus management

Synchronise courses, enrolments and grades automatically.

Upgrades & migration

To new versions, including an inventory of all third-party plugins.

Review of existing plugins

Code quality and security, before a plugin goes into production.

2What we look for

Four lines where most vulnerabilities in Moodle plugins originate. We have found them in other people's code often enough.

require_login($course, false, $cm);
$context = context_module::instance($cm->id);
require_capability('mod/example:view', $context);       ①

$id = required_param('id', PARAM_INT);                  ②
$entry = $DB->get_record('example_entries',
    ['id' => $id, 'exampleid' => $cm->instance],        ③
    '*', MUST_EXIST);

echo $OUTPUT->render_from_template('mod_example/entry', [
    'title' => format_string($entry->name),             ④
]);

On top of that: Moodle coding guidelines, PHPUnit and Behat in CI via moodle-plugin-ci, and a security review before every delivery. More under Security.

3Example

SituationA plugin from the Moodle 3.x days, the developer can no longer be reached, and the next upgrade is due.

4Frequently asked questions