Home Home > 2009 > 06 > 26 > GSoC – summary of this week’s meeting
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

GSoC – summary of this week’s meeting

June 26th, 2009 by

The task for this week was to add support to the frontend so that desktop clients like osc can add the oauth specific parameters to the http “Authorization” header. The ruby library was already able to handle this and therefore I only needed to do a very small change in our urllib2 OAuthHandler which is used by osc.

Using the Authorization header has one drawback:
– the current flow looks like the following: a client makes an unauthorized API request, the API sends back a 401 to tell the client that it needs to authenticate. Therefore the response also contains the following http header: ‘WWW-Authenticate: basic realm=”Frontend login” ‘. This indicates that the client should use basic auth to authenticate with the API. The question is how we can tell the client that it could also use oauth? Sending back something like ‘WWW-Authenticate: basic, oauth realm=”Frontend login”‘ will probably break some clients. Fortunately darix had a great idea: the client simply tells the server which auth methods it supports. This can be done by adding a new http header like ‘Accept-Authentication: OpenID; OAuth;q=0.8, digest;q=0.7, Basic;q=0.5″ ‘ to each request (q indicates which method is preferred, see other http headers like ‘Accept-Language’ for the details). If the API needs authorization it looks at this header and picks the “preferred” method from this list and sends back ‘WWW-Authenticate: <preferred_and_supported_method>, realm=”Frontend login”‘ ‘. In case the Accept-Authentication header is omitted the application’s default method is used (in our case basic auth). Another thing which needs to be discussed is how the API should behave if the client only accepts methods which aren’t supported by the API (e.g. should the API send back a 401 or 406?).

Apart from thinking about this the other task for this week(end) is to add an UI for managing oauth tokens etc. The first part of this task is to decide which tasks the UI should support (like revoking tokens, authorize tokens etc.).

The next meeting will be on monday to discuss the first results.

Both comments and pings are currently closed.

Comments are closed.