Feedback wanted on new flatpak purchases support

[Philip Withnall]

On Fri, 2019-12-13 at 11:38 +0100, Alexander Larsson wrote:
> On Thu, Dec 12, 2019 at 3:51 PM Philip Withnall <
> philip at tecnocode.co.uk> wrote:
> > 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?

I think you’ve answered the question with your description of the
control flow below, thanks.

> 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.

Wouldn’t hurt to add the collection-id to the dicts.

> > > 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.

For anyone else following along, this is now implemented as 
https://github.com/flatpak/flatpak/pull/3309.

Philip