Entitlement server and protected repos support

[Damián Nohales]

Hello Alex,

Thanks for responding.

Yes, I agree with you, I expect the token request to take a long time, even
you a UI and the possibility of cancellation.

I suspect I'm gonna encounter all the problems on the way during the
implementation and the final interface would be slightly different.

Gonna see the Portal code, thanks!

El vie., 7 de junio de 2019 05:37, Alexander Larsson <alexl at redhat.com>
escribió:

> On Fri, Jun 7, 2019 at 12:02 AM Damián Nohales <damian at endlessm.com>
> wrote:
> > Hello Alex,
> >
> > So, after talking to the team at Endless, specifically about this
> > situation. We are finally thinking of this approach:
> >
> > The repo will have in its configuration (in the summary) two new options:
> >   * xa.authenticator: Which can be a query string with multiple
> > parameters describing the way the repo should manage the
> > authentication.
> >   * xa.authenticator-gpg-key: The public key the repo must use to
> > validate pull tokens.
> >
> > On the other hand, we will create a D-Bus interface called
> > org.flatpak.Authenticator, anything outside Flatpak could implement
> > that interface, right now, I'm thinking that interface could have only
> > one method called GetToken which accepts what's inside the
> > authenticator, the refs that Flatpak wants a token for and basic
> > information about the remote (like URL and Collection ID), and returns
> > the bearer token to be used in the pull requests.
> >
> > So basically Flatpak doesn't know anything about how to get the token
> > at all, but it delegates that work to the available services
> > implementing org.flatpak.Authenticator. It only knows what is returned
> > there, must be used as Bearer token afterwards (unless we want to be
> > flexible there too). Depending on the information in xa.authenticator,
> > the authenticator could try to fetch the token, or ignore the request
> > and return null. When Flatpak detects an authenticator returning
> > something, it stops calling the rest.
>
> I think this sounds good. But, the devil is in the details, and in
> particular I think you need to be very careful when designing the
> org.flatpak.Authenticator API. Your initial implementation will just
> immediately return the endless entitlement data, so it is very easy
> for the API to be modelled on that and become token =
> send_token_request_and_wait_for_response (bus, config). However,
> conceptually the authentication API can do some form of authentication
> UI as well as potentially problematic network i/o. So, one has to take
> into consideration that this API can:
>  * Block
>  * Take a long time
>  * Run into network/connectivity issue
>  * Be cancelled by the user
>
> And the above issues must be taken into account when designing the
> dbus API. For instance it can't be a regular single-message send
> request + get response, because those typically times out in 30 sec.
> Also, the flatpak library code wrapping the dbus calls will also look
> different if the call is something you can expect to call
> synchronously, or something that is blocking and does interaction.
>
> I recommend that you look at the portal dbus API, as it has similar
> requirements. For example, the base portal request is:
>
> https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Request.xml
> Which takes what is really a single portal request and makes an object
> representing it that will eventually get a response as a signal, or
> that can be cancelled from the caller side if the user is not
> interested in the request anymore.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20190607/dee1d98a/attachment.html>