Note: You are currently viewing documentation for Moodle 2.2. Up-to-date documentation for the latest stable version is available here: External services security.

Development:External services security: Difference between revisions

From MoodleDocs
Line 19: Line 19:


==API layers==
==API layers==
Three layers:
# external server interface (SOAL, REST, RSS, etc.) - deals with tokens, emulates user session
# 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
# low level internal API - as fast as possible, basic param validation, no access control, must not touch $USER, $SESSION, $_GET or $_POST!


=Implementation=
=Implementation=

Revision as of 20:52, 7 April 2009

Template: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