Development:External services security: Difference between revisions
From MoodleDocs
| Line 10: | Line 10: | ||
* chat_sid tokens - generated separately for each user in each chat | * chat_sid tokens - generated separately for each user in each chat | ||
* calendar hash from user name, password and salt | * calendar hash from user name, password and salt | ||
* hacky cookie emulation in visual gradebook plugin | |||
==Types of token== | ==Types of token== | ||
Revision as of 20:54, 7 April 2009
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
- hacky cookie emulation in visual gradebook plugin
Types of token
We need several types of tokens
- token sharing/linked to active session, should time out or be destroyed at the same time as session (ex.: chat) - shared $SESSION and $USER
- 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:
- external server interface (SOAL, REST, RSS, etc.) - deals with tokens, emulates user session, parameter processing
- 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, must not use has_capability() or require_login()!
