<div dir="auto"><div>Hello Alex,<div dir="auto"><br></div><div dir="auto">Thanks for responding.</div><div dir="auto"><br></div><div dir="auto">Yes, I agree with you, I expect the token request to take a long time, even you a UI and the possibility of cancellation.</div><div dir="auto"><br></div><div dir="auto">I suspect I'm gonna encounter all the problems on the way during the implementation and the final interface would be slightly different.</div><div dir="auto"><br></div><div dir="auto">Gonna see the Portal code, thanks!</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El vie., 7 de junio de 2019 05:37, Alexander Larsson <<a href="mailto:alexl@redhat.com">alexl@redhat.com</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jun 7, 2019 at 12:02 AM Damián Nohales <<a href="mailto:damian@endlessm.com" target="_blank" rel="noreferrer">damian@endlessm.com</a>> wrote:<br>
> Hello Alex,<br>
><br>
> So, after talking to the team at Endless, specifically about this<br>
> situation. We are finally thinking of this approach:<br>
><br>
> The repo will have in its configuration (in the summary) two new options:<br>
> * xa.authenticator: Which can be a query string with multiple<br>
> parameters describing the way the repo should manage the<br>
> authentication.<br>
> * xa.authenticator-gpg-key: The public key the repo must use to<br>
> validate pull tokens.<br>
><br>
> On the other hand, we will create a D-Bus interface called<br>
> org.flatpak.Authenticator, anything outside Flatpak could implement<br>
> that interface, right now, I'm thinking that interface could have only<br>
> one method called GetToken which accepts what's inside the<br>
> authenticator, the refs that Flatpak wants a token for and basic<br>
> information about the remote (like URL and Collection ID), and returns<br>
> the bearer token to be used in the pull requests.<br>
><br>
> So basically Flatpak doesn't know anything about how to get the token<br>
> at all, but it delegates that work to the available services<br>
> implementing org.flatpak.Authenticator. It only knows what is returned<br>
> there, must be used as Bearer token afterwards (unless we want to be<br>
> flexible there too). Depending on the information in xa.authenticator,<br>
> the authenticator could try to fetch the token, or ignore the request<br>
> and return null. When Flatpak detects an authenticator returning<br>
> something, it stops calling the rest.<br>
<br>
I think this sounds good. But, the devil is in the details, and in<br>
particular I think you need to be very careful when designing the<br>
org.flatpak.Authenticator API. Your initial implementation will just<br>
immediately return the endless entitlement data, so it is very easy<br>
for the API to be modelled on that and become token =<br>
send_token_request_and_wait_for_response (bus, config). However,<br>
conceptually the authentication API can do some form of authentication<br>
UI as well as potentially problematic network i/o. So, one has to take<br>
into consideration that this API can:<br>
* Block<br>
* Take a long time<br>
* Run into network/connectivity issue<br>
* Be cancelled by the user<br>
<br>
And the above issues must be taken into account when designing the<br>
dbus API. For instance it can't be a regular single-message send<br>
request + get response, because those typically times out in 30 sec.<br>
Also, the flatpak library code wrapping the dbus calls will also look<br>
different if the call is something you can expect to call<br>
synchronously, or something that is blocking and does interaction.<br>
<br>
I recommend that you look at the portal dbus API, as it has similar<br>
requirements. For example, the base portal request is:<br>
<a href="https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Request.xml" rel="noreferrer noreferrer" target="_blank">https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Request.xml</a><br>
Which takes what is really a single portal request and makes an object<br>
representing it that will eventually get a response as a signal, or<br>
that can be cancelled from the caller side if the user is not<br>
interested in the request anymore.<br>
</blockquote></div></div></div>