Development: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
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.
