Feedback wanted on new flatpak purchases support

[Alexander Larsson]

On Thu, Dec 12, 2019 at 3:51 PM Philip Withnall <philip at tecnocode.co.uk> wrote:
>
> Hey,
>
> Sorry for the delay in replying about this. It all looks pretty cool;
> nice work!
>
> On Thu, 2019-11-28 at 16:49 +0100, Alexander Larsson wrote:
> > I'm interested in feedback on the overal approach here, as well as
> > APIs and how well it covers what people need for flatpak.
> >
> > The authenticator dbus APIs are documented here:
> >
> >
> > https://github.com/flatpak/flatpak/blob/master/data/org.freedesktop.Flatpak.Authenticator.xml
>
> Doesn’t seem to include any handling for collection IDs — what do you
> have in mind for the control flow when someone’s doing a P2P pull (even
> in the case where that P2P pull ends up being satisfied by a remote web
> server rather than a LAN peer or USB stick)?

Hmm, not sure exactly what you mean here?

We could (should maybe) pass the collection id of the ref as well as
the remote name, so that the authenticator can take that into account
when deciding what to do about the ref. In todays release (1.5.2) i
actually extended this API so that there are some more information
like the remote uri and some gvariant dicts so we can easily add stuff
as needed. Adding the collection-id should be an easy addition to
this.

However, in practice I don't think whether p2p or not is involved
makes much difference to the authenticator. If you for example set up
the "endless" remote to use the endless authenticator, and we pull via
p2p, we will ask it for a token, it will decide by talking to some
endless server, and then it will set the token in the header in the
pull request, be it p2p or not.

> > The libflatpak APIs for frontend integration, are documented here:
> >
> >
> > https://flatpak.readthedocs.io/en/latest/libflatpak-api-reference.html#FlatpakTransaction
>
> The only new stuff there are the FlatpakTransaction::webflow-start and
> FlatpakTransaction::webflow-done signals, right?

And flatpak_transaction_abort_webflow(). Although the latest version
also has a basic-auth-start
signal and a flatpak_transaction_complete_basic_auth() function.

> Presumably that means that if an authenticator uses its own UI (rather
> than a URI), it just asynchronously does that part-way through
> flatpak_transaction_run(), and the transaction blocks until it
> completes.

Yes, and even more so, in the latest version it optionally passes a
portal-style parent window argument. Which in the API is set with
flatpak_transaction_set_parent_window(). This way the authenticator
can ensure that its dialogs are properly parented to the client app.

> That seems fine, but what if the FlatpakTransaction is being
> run by a background service and doesn’t want to cause UIs to pop up?
> Perhaps there should be a ALLOW_INTERACTIVE or DISALLOW_INTERACTIVE
> flag passed to FlatpakTransaction (and from there, passed through to
> the authenticator)? If interactivity were disallowed, and the
> authenticator required it, then authentication should fail.

Hmm, yeah, that sounds useful.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com