On Mon, 2013-03-11 at 11:28 -0700, Toshio Kuratomi wrote: > On Mon, Mar 11, 2013 at 07:05:57PM +0100, Pierre-Yves Chibon wrote: > > * Possibility to restrict a token's action > > - Well this can already be discussed. It has been made clear that it > > is a all or nothing mechanism (a bit like when installing an app on an > > Android phone, you have the choice between giving this app access to > > your contact, the gps... or not using the app). Meaning, since most if > > not all our tools will be able to perform most of the action possible on > > the website, it's pretty much coming back on having one big token to use > > the APi of the website. > > > You'd need a big token if you intend to use all of the api. You wouldn't if > you only intend to use a portion of it. > > The thing that we seem to be getting hung up on is that a CLI application > can potentially access all of the API of a single resource server and > potentially other resource servers as well. hm, atm we have one CLI per application, tbh, I'd rather keep it this way. > What I would propose here is > that we utilize puiterwijk and my thoughts on emulating sessions to have one > big token per resource server. So we're back pretty much on 1 token / application (pkgdb, copr...) which would be the approach we would take if we implement token w/o oauth. > But that token has a very limited lifetime. > That makes it inappropriate for scripting and cron jobs. When you want to > make a shell script that runs on its own, you need to get a different token > that has more limited permissions. That sort of token would have a longer > or perhaps indefinite lifetime (indefinite when you consider the presence of > refresh tokens). Meaning, we need to have a way to generate a token for the user (where he can choose which permission he associates with the token), no? > > Actually, how are the CLI supposed to work if we don't integrate oauth > > with goa? > > There are several methods depending on how much we want the user to trust > the commandline app. puiterwijk and I agreed that we could use the > "Resource owner password credentials" method -- this would require giving > the username and password to the CLI app which would then perform the > necessary calls to the resource server to get the access token. It could > also be done using one of the other methods if you don't want to require the > user to trust the CLI app we write :-) But then that's pretty much what we are already doing with for example pkgdb-cli and to me that defeats a bit the point of tokens, where would we use them then? I my idea, tokens are there to replace the use of the password which if intercept gives you access to more than the token itself (ie: with your password I can change your password, with your api token I can change the ACLs on your package) Pierre _______________________________________________ infrastructure mailing list infrastructure@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/infrastructure
