External services security: Difference between revisions
From MoodleDocs
No edit summary |
No edit summary |
||
Line 3: | Line 3: | ||
Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies. | Descriptions of security framework for web services, also used for RSS feeds, embedded application and similar parts that can not use normal HTTP cookies. | ||
=Current solutions= | =Overview= | ||
==Current solutions== | |||
* user keys for gradebook import and export - see require_user_key_login() and db table ''user_private_key'' | * 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 | * open RSS feeds - no security at all | ||
Line 9: | Line 11: | ||
* calendar hash from user name, password and salt | * calendar hash from user name, password and salt | ||
=Types of token= | ==Types of token== | ||
We need several types of tokens | 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 | # token sharing/linked to active session, should time out or be destroyed at the same time as session (ex.: chat) - shared $SESSION and $USER | ||
Line 15: | Line 17: | ||
In the second case we need to deal with performance problems if many repeated request expected. This can be dealt with alter. | In the second case we need to deal with performance problems if many repeated request expected. This can be dealt with alter. | ||
=Implementation= | |||
=See also= | =See also= |
Revision as of 20:36, 7 April 2009
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
- 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.