[PATCH 4/6] Create the /api/ page providing the API token and information

Bohuslav Kabrda bkabrda at redhat.com
Tue Jan 8 09:21:18 UTC 2013


----- Original Message -----
> On Tue, Jan 08, 2013 at 03:41:17AM -0500, Bohuslav Kabrda wrote:
> > ----- Original Message -----
> > > On Tue, Jan 08, 2013 at 02:45:17AM -0500, Bohuslav Kabrda wrote:
> > > > ----- Original Message -----
> > > > > The API page aims at providing information about the API
> > > > > itself
> > > > > and
> > > > > how to use it.
> > > > > Additionally, if you are logged-in, this page gives you your
> > > > > own
> > > > > API token (needed to call the API), its expiration date (as
> > > > > each
> > > > > token is valid only 30 days) and a way to generate a new
> > > > > token.
> > > > > ---
> > > > 
> > > > Hey Pingou,
> > > > thanks for the patches. The first three are ok and I'll apply
> > > > them.
> > > > As for the token authentication, I'm not generally opposed to
> > > > that,
> > > > but:
> > > > 1) the alembic migration fails with
> > > > 'Cannot add a NOT NULL column with default value NULL u'ALTER
> > > > TABLE
> > > > user ADD COLUMN api_token'
> > > > so the migration must contain a sane value for already existing
> > > > users. Also the migration should create an expired token, I
> > > > think.
> > > > Just to make sure we're safe with the auto-inserted empty
> > > > token...
> > > 
> > > Good point, I thought about it but forgot when I wrote the patch.
> > > Good idea with
> > > the expired token, that's an easy solution: default token 'abc'
> > > expiration date:
> > > '2000-01-01' and problem solve :)
> > > 
> > > > 2) What exactly do we need the token for? Anything else than
> > > > user
> > > > comfort? If not, I think that a cookie based permanent login
> > > > would
> > > > be a good standard solution for this problem.
> > > 
> > > The idea of the token is to allow creating a CLI for coprs, this
> > > way
> > > one can
> > > have a ~/.config/coprs file containing the token and call the API
> > > from the
> > > website to perform the different action we would like to see in
> > > the
> > > CLI.
> > > 
> > 
> > Yeah, CLI is on my TODO list :)
> > But my plan was to utilize the fedora certificates, that are
> > already used for e.g. koji builds. This way, every user would be
> > able to generate his certificate and most of the potential copr
> > users (=packagers) already have that certificate. So I think it
> > would be a more comfortable solution (although I haven't discussed
> > this possibility with anyone yet and I'm not even sure it would be
> > possible).
> 
> hm, iirc, the certificates is used for the upload on koji. I'm not
> sure it's
> used to start the builds (might be wrong though).
> 
> After the main point I can think of in favor of the token (beside the
> technical
> difference) is the fact that it makes the application more generic
> than Fedora
> and after all the trac page seems to imply there is interest also
> from outside
> our Fedora circle.
> 

Ok, agreed. I'll accept the patches. Will you fix the DB migration and initial values or should I do that?
Thanks.

> Pierre
> _______________________________________________
> copr-devel mailing list
> copr-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/copr-devel
> 

-- 
Regards,
Bohuslav "Slavek" Kabrda.


More information about the copr-devel mailing list