Note:

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

External services security

From MoodleDocs

Moodle 2.0


Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies.

Overview

Current solutions

  • user keys for gradebook import and export - see require_user_key_login() and db table user_private_key
  • open RSS feeds - no security at all
  • chat_sid tokens - generated separately for each user in each chat
  • calendar hash from user name, password and salt

Types of token

We need several types of tokens

  1. token sharing/linked to active session, should time out or be destroyed at the same time as session (ex.: chat) - shared $SESSION and $USER
  2. permanent token, revokeable by user (ex.: RSS feeds, web services) - emulated $SESSION and $USER

In the second case we need to deal with performance problems if many repeated request expected. This can be dealt with alter.

API layers

Three layers:

  1. external server interface (SOAL, REST, RSS, etc.) - deals with tokens, emulates user session
  2. public PHP API - functions usable directly from PHP, list generated from inline PHP docs, need to verify all parameters and access control, may access $USER, should not manipulate $SESSION directly, must not read $_POST or $_GET
  3. low level internal API - as fast as possible, basic param validation, no access control, must not touch $USER, $SESSION, $_GET or $_POST!

Implementation

See also