Message-ID: <8d25249f9fc45e951deacd3b26084324cb70d08b.camel@liw.fi>
From: Lars Wirzenius <liw@liw.fi>
To: ick discussions <ick-discuss@ick.liw.fi>
Date: Thu, 06 Sep 2018 21:16:47 +0300
User-Agent: Evolution 3.30.0-1 
Mime-Version: 1.0
Subject: Ick planning: what next?
Precedence: list
Content-Type: multipart/mixed; boundary="===============6309345869005290914=="
Mime-version: 1.0
Sender: ick-discuss-bounces@ick.liw.fi
Errors-To: ick-discuss-bounces@ick.liw.fi


--===============6309345869005290914==
Content-Type: multipart/signed; micalg="pgp-sha512";
 protocol="application/pgp-signature"; boundary="=-W0owP7QZKqnCdVp5zpkK"


--=-W0owP7QZKqnCdVp5zpkK
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Ick has been a little on the backburner lately, while I sort out some
personal and work stuff. However, it would be good to have a little
discussion about where we should take ick next.

Current status is that the controller works and builds happen. There is
_very_ rudimentary web application.

It is clear to me, after talking to various people, that a web interface
for ick should be a high priority. I'm not good with front-end web stuff,
so that's something I'd really like help with.

A pre-requisite for an ick web application is to make end-user
authentication more sensible. At the moment, the web application allows the
user to log in, and that works. However, the command line application,
icktool, requires a different set of credential.

Technically, the web application uses the OpenID Connect authorization code
flow for login, and ickdtool uses the OAuth2 client credentials grant. I
think this needs to be handled so that the web application is changed to
allow the user to create an "API token", which icktool can use to access
the  controller. This allows the user to only have one set of credentials,
which is much more sane.

The API token will be an extension to OIDC, and will allow icktool to
retreive a standard access token, for actually accessing the controller
API. The access token will identify the user.

When all API use identifies the user, we can change ick to assign an owner
to each resource (project, pipeline, build, build log, artifact), and
restrict users to only see, create, modify, and delete their own artifacts.
This, in turn, will take ick much closer to being a "hostable service",
where different users are more or less safe from each other.

What do you all think about this? Is there something you'd really like to
see in ick, before or after the above? Please say, the floor is open for
dreams, fantasies, and wishes.

The ick web application will be using the RESTful HTTP APIs of the various
ick components, but can otherwise be separate from them. It can be
implemented in any language and way, as long as the user is happy to use it
and it uses Qvisqve for end-user authenticattion and the ick APIs for drive
ick. I'd like the web application to be free software, built using tools in
Debian, and have no dependencies outside what is packaged in Debian.
However, I realise that's a difficult request in the modern world of web
development, so I'm willing to discuss the build and runtime dependencies,
though not the freedom.

If web application front-ends are something you like working on, please say
so. I'd really appreciate any help with the front-end.

--=-W0owP7QZKqnCdVp5zpkK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEETNTnrewG6wEE1EJ3bC+mFux6IDEFAluRbw8ACgkQbC+mFux6
IDHS9xAAn1UV61Sfhi9vF8Qu9EUVvFrxavzHg22C6kFh3X8mgBsL402qSLPX4FFp
5wzWQSvxIOCszKrx0UdOyyAftXhqqjMy7V5q+2VZjpA4kZUVLpD+IdzVKn45M+99
ldjHEz7U+i0iJQxUQfKsJqG60EqjbqUvNSuu99xlPIJbxthCRg8Y2+O6dwSqZuxv
U5/qmFGKKV+gMv+dFUh+neV6btyBZqJ9PtK/t1JjmXBKV5naDZMOrm0sONTCj+Y/
alXKRpUGOiBXsDdOeXZmIodozBA7ubaV6ffsZ5Mrigt31rPgNsfHbs+eyMmtFlKb
NiJUPB/Q+H7sMMbVq+rv734tiaFy1XnoMMGagQUocgiyEfdc2oAwdDFBnAMTH4OG
Pi3atlNr9G6oGuE+wue2rhkpT2jLzuhcZMidqi5GQkORTrYi0bYeys7ASyZwJ54K
tbe3rEqiFFjfikRs68mPD5WJ3C0vMcPv/3kUNtZd0k7zrKioxWuHvzx6PK/YuJQO
WX+MM42L+U6rCNsH/Abt4HXBzX87DH38LNZMv3UbdNO0C4szx2kWaWSvUYZh4y9G
zv5Uly+UeuD0FfaKemjyqSHD2fR9XJveY3IgK3p+wmfTCCZzUyBbW6UO2CRzfUVZ
YJT3GuuVYigxGyzAhNN9eBLcxvuxX0tX8DrOA2Af9zAiKtS26v4=
=ZqMq
-----END PGP SIGNATURE-----

--=-W0owP7QZKqnCdVp5zpkK--


--===============6309345869005290914==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
ick-discuss mailing list
ick-discuss@ick.liw.fi
https://listmaster.pepperfish.net/cgi-bin/mailman/listinfo/ick-discuss-ick.liw.fi

--===============6309345869005290914==--