Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

MNET 1.0 RPC: Difference between revisions

From MoodleDocs
(Created page with "{{obsolete}} As part of the Community hub infrastructure, we need to define RPC calling conventions... Moodle's APIs follow several principles that make them scalable annd ...")
 
m (Text replacement - "<code>" to "<syntaxhighlight lang="php">")
Line 25: Line 25:
Instead, the rpc layer expects one of several prefixes in the method name
Instead, the rpc layer expects one of several prefixes in the method name


* <code>mod_</code>
* <syntaxhighlight lang="php">mod_</code>
* <code>auth_</code>
* <syntaxhighlight lang="php">auth_</code>
* <code>enrol_</code>
* <syntaxhighlight lang="php">enrol_</code>


==== For modules ====
==== For modules ====


An RPC call to <code>mod_forum_dofoobar()</code> rpc call triggers:
An RPC call to <syntaxhighlight lang="php">mod_forum_dofoobar()</code> rpc call triggers:


* <code>include_once(mod/forum/lib.php)</code>
* <syntaxhighlight lang="php">include_once(mod/forum/lib.php)</code>
* check for <code>function_exists("forum_rpc_dofoobar_enabled")</code>
* check for <syntaxhighlight lang="php">function_exists("forum_rpc_dofoobar_enabled")</code>
* <code>if (forum_rpc_dofoobar_enabled())</code>  
* <syntaxhighlight lang="php">if (forum_rpc_dofoobar_enabled())</code>  
* then invoke <code>forum_rpc_dofoobar()</code> with the parameters received...
* then invoke <syntaxhighlight lang="php">forum_rpc_dofoobar()</code> with the parameters received...


:'''Note:''' <code>rpc_</code> is an arbitrary prefix that makes it clear that the function is for remote invocation. The <code>_enabled()</code> function must exist and return true for added security. make it really hard for a develper to expose something accidentally
:'''Note:''' <syntaxhighlight lang="php">rpc_</code> is an arbitrary prefix that makes it clear that the function is for remote invocation. The <syntaxhighlight lang="php">_enabled()</code> function must exist and return true for added security. make it really hard for a develper to expose something accidentally


==== For auth and enrol plugins ====
==== For auth and enrol plugins ====


An RPC call to <code>enrol_ldap_dofoobar()</code> rpc call triggers:
An RPC call to <syntaxhighlight lang="php">enrol_ldap_dofoobar()</code> rpc call triggers:


* <code>include_once(enrol/ldap/enrol.php)</code>
* <syntaxhighlight lang="php">include_once(enrol/ldap/enrol.php)</code>
* instanciate the class
* instanciate the class
* check for <code>method_exists($obj, "rpc_dofoobar_enabled")</code>
* check for <syntaxhighlight lang="php">method_exists($obj, "rpc_dofoobar_enabled")</code>
* <code>if ($obj->rpc_dofoobar_enabled())</code>  
* <syntaxhighlight lang="php">if ($obj->rpc_dofoobar_enabled())</code>  
* then invoke <code>$obj->rpc_dofoobar()</code> with the parameters received...
* then invoke <syntaxhighlight lang="php">$obj->rpc_dofoobar()</code> with the parameters received...

Revision as of 13:02, 14 July 2021

Warning: This page is no longer in use. The information contained on the page should NOT be seen as relevant or reliable.


As part of the Community hub infrastructure, we need to define RPC calling conventions...

Moodle's APIs follow several principles that make them scalable annd flexible.

  • They are "Just In Time discoverable" rather than all registered at runtime. This is a good optimization for HTTP's statelesness.
  • Once an entry point is hit (a webpage in moodle, for instance) the module code author is in control. The framework doesn't limit what kinds of interactions can happen.

So we want to preserve those capabilities... Additionally, we want to make sure the RPC calls are safe, and cannot be exposed by accident.

Outline of a new mnet API

Calls can be exposed via the mnet API by

  • Moodle core
  • Moodle auth plugins
  • Moodle enrol plugins
  • Moodle modules

How the RPC calls are dispatched

The dispatcher is slightly different from a conventional XML-RPC dispacher that gets the available methods registered at startup. (It is too costly to walk all the available modules and plugins on each invocation.)

Instead, the rpc layer expects one of several prefixes in the method name

  • <syntaxhighlight lang="php">mod_
  • <syntaxhighlight lang="php">auth_
  • <syntaxhighlight lang="php">enrol_

For modules

An RPC call to <syntaxhighlight lang="php">mod_forum_dofoobar() rpc call triggers:

  • <syntaxhighlight lang="php">include_once(mod/forum/lib.php)
  • check for <syntaxhighlight lang="php">function_exists("forum_rpc_dofoobar_enabled")
  • <syntaxhighlight lang="php">if (forum_rpc_dofoobar_enabled())
  • then invoke <syntaxhighlight lang="php">forum_rpc_dofoobar() with the parameters received...
Note: <syntaxhighlight lang="php">rpc_ is an arbitrary prefix that makes it clear that the function is for remote invocation. The <syntaxhighlight lang="php">_enabled() function must exist and return true for added security. make it really hard for a develper to expose something accidentally

For auth and enrol plugins

An RPC call to <syntaxhighlight lang="php">enrol_ldap_dofoobar() rpc call triggers:

  • <syntaxhighlight lang="php">include_once(enrol/ldap/enrol.php)
  • instanciate the class
  • check for <syntaxhighlight lang="php">method_exists($obj, "rpc_dofoobar_enabled")
  • <syntaxhighlight lang="php">if ($obj->rpc_dofoobar_enabled())
  • then invoke <syntaxhighlight lang="php">$obj->rpc_dofoobar() with the parameters received...