Changes

Jump to: navigation, search

CloudServices/Sagrada/TokenServer

2 bytes added, 18:17, 2 February 2012
no edit summary
* need support for future developments like bucketed assignment
* Needs to be a system that scales infinitely.
 
= APIS v1.0 =
 
'''Unless stated otherwise, all APIs are using application/json for the requests and responses content types.'''
 
== GET /1.0/<app_name>/token ==
 
Asks for new token given some credentials in the Authorization header.
 
By default, the authentication scheme is Browser ID but other schemes can potentially be used if supported by the login server. '''app_name''' is the name of the application to access, like '''sync'''.
 
Example for Browser-Id:
<pre>
GET /1.0/sync/token
Host: token.services.mozilla.com
Content-Type: application/json
Authorization: Browser-ID <assertion>
</pre>
 
This API returns several values in a json mapping:
 
* '''oauth_consumer_key''' - a signed authorization token, containing the user's id and expiration
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''service_entry''': a node url
 
Example:
 
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
 
{'oauth_consumer_key': <token>,
'oauth_consumer_secret': <derived-secret>,
'service_entry': <node>,
}
</pre>
 
All errors are also returned as json responses, following the structure described in Cornice.
 
XXX need to document this in Cornice
 
Status codes and error codes:
* 404 : unknown URL (0), or unsupported application (1).
* 400 : malformed request - missing option or bad values(2) or malformed json (3) or unsupported authentication protocol (4)
* 401 : authentication failed or protocol not supported (5). The response in that case will contain WWW-Authenticate headers (one per supported scheme)
* 405 : unsupported method (6)
* 406 : unacceptable - the client asked for an Accept we don't support (7)
* 503 : service unavailable (ldap or snode backends may be down) (8)
 
= Proposed Design =
# the server process the request [Sync = I/O Bound]
= APIS v1.0 =
 
'''Unless stated otherwise, all APIs are using application/json for the requests and responses content types.'''
 
== GET /1.0/<app_name>/token ==
 
Asks for new token given some credentials in the Authorization header.
 
By default, the authentication scheme is Browser ID but other schemes can potentially be used if supported by the login server. '''app_name''' is the name of the application to access, like '''sync'''.
 
Example for Browser-Id:
<pre>
GET /1.0/sync/token
Host: token.services.mozilla.com
Content-Type: application/json
Authorization: Browser-ID <assertion>
</pre>
 
This API returns several values in a json mapping:
 
* '''oauth_consumer_key''' - a signed authorization token, containing the user's id and expiration
* '''oauth_consumer_secret''' - a secret derived from the shared secret
* '''service_entry''': a node url
 
Example:
 
<pre>
HTTP/1.1 200 OK
Content-Type: application/json
 
{'oauth_consumer_key': <token>,
'oauth_consumer_secret': <derived-secret>,
'service_entry': <node>,
}
</pre>
 
All errors are also returned as json responses, following the structure described in Cornice.
 
XXX need to document this in Cornice
 
Status codes and error codes:
* 404 : unknown URL (0), or unsupported application (1).
* 400 : malformed request - missing option or bad values(2) or malformed json (3) or unsupported authentication protocol (4)
* 401 : authentication failed or protocol not supported (5). The response in that case will contain WWW-Authenticate headers (one per supported scheme)
* 405 : unsupported method (6)
* 406 : unacceptable - the client asked for an Accept we don't support (7)
* 503 : service unavailable (ldap or snode backends may be down) (8)
= Phase 1 =
Confirm
927
edits

Navigation menu