← Back to team overview

canonical-ci-engineering team mailing list archive

Re: cli authentication design decisions

 

I agree that browser based makes the most sense. As a first pass, we should
be able to make progress with something very simple: provide a token that
users can copy and paste, download a credentials file or do some
javascripty thing to save it.

I assuming these CLI tokens would be set to never expire. Do we have a way
to revoke them? Do we need one?

Francis


On Wed, Aug 27, 2014 at 10:49 AM, Joe Talbott <joe.talbott@xxxxxxxxxxxxx>
wrote:

> All,
>
> Siva and I have been working on getting authentication working in the
> UCI Engine and the cli in particular.  There are a few methods for
> authorizing an access token via oauth2 for an insecure client.  Most
> notably browser based and password based[1].  I'm thinking that we don't
> want to mess with user passwords and would take that option off the
> table.  This leads me to think we could add an access_token end-point on
> the ticket-system (accessible via the webui-apache proxy) that simply
> does the standard web server based authentication we're currently doing
> for the webui and prints out the access token for the user to store in
> their keyring.  I'm not sure if/how we can automate this further.  Does
> anyone have ideas, suggestions, complaints, or other comments?
>
> Thanks,
> Joe
>
>
> [1]
> http://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified#browser-based-apps
>
> --
> Mailing list: https://launchpad.net/~canonical-ci-engineering
> Post to     : canonical-ci-engineering@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~canonical-ci-engineering
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Francis Ginther
Canonical - Ubuntu Engineering - Continuous Integration Team

Follow ups

References