Research for app purchases

Tue Oct 15 15:53:26 UTC 2019

Related to my previous email, this could be the workflow for flatpak
purchases

# Login to flathub remote and store credentials (token) locally
flatpak remote-login flathub
 Username:email at example.com
 Password:*******

# Install free (as a bier) app
flatpak install flathub org.gnome.Polari
 (Normal installation)

# Install app that I have purchased previously
flatpak install flathub com.exemple.AppThatRequiresPaymentPreviouslyBought
 (Normal installation)

# Install app that I need to purchase
flatpak install flathub com.exemple.AppThatRequiresPayment
Error: this app requires purchase. Please go to
https://flathub.org/apps/com.exemple.AppThatRequiresPayment
      or use gnome-software or another compatible client to complete
purchase

# List all my purchases at flathub
flatpak remote-ls-purchases flathub

# Logout (clear credentials)
flatpak remote-logout flathub

Missatge de Jorge García <jgarciao at gmail.com> del dia dt., 15 d’oct. 2019 a
les 17:33:

>
> Hi,
>
> > standard way or a CLI app to do a web-based authentication process and
> then get data back from the web authenticator* is for it to run a simple
> HTTP
> > server on localhost, and pass the URI to that to the web authenticator
>
> Docker uses another way to authenticate to registry servers like Docker
> Hub:
> 1) The user creates an account via web browser at https://hub.docker.com,
> obtaining a username and password
> 2) On the command line, the user executes "docker login" and enters
> username and password
> 3) If the username and password where correct the remote server provides a
> token to the docker cli, stored in a credentials store, which by default is
> just a file $HOME/.docker/config.json but it can be others documented here
> <https://docs.docker.com/engine/reference/commandline/login/>
> 4) Each time the cli needs to do something with the remote server (like
> docker push ...) it includes the token in the http header of the api call
> 5) docker logout removes the token from the store
>
> This is explained (much better) here:
> - https://docs.docker.com/engine/reference/commandline/login/
> - https://docs.docker.com/registry/spec/auth/token/
>
> Regards,
> Jorge
>
>
>
>
>
>
>
> Missatge de Philip Withnall <philip at tecnocode.co.uk> del dia dt., 15
> d’oct. 2019 a les 17:15:
>
>> On Fri, 2019-10-11 at 10:02 +0200, Alexander Larsson wrote:
>> > On Thu, Oct 10, 2019 at 8:01 PM Dan Nicholson <nicholson at endlessm.com
>> > > wrote:
>> > > On Fri, Oct 4, 2019 at 3:28 AM Alexander Larsson <alexl at redhat.com>
>> > > wrote:
>> > > > I'm leaning towards model 2 for the authentication, although
>> > > > we're going
>> > > > to require a fully generic web flow for the actual purchase part.
>> > >
>> > > I am far from the expert on designing this part of the interaction.
>> > > One thing I worry about, though, is that authentication scheme and
>> > > data is inherently specific to the authenticator. That's why we
>> > > specified the authenticator as a separate component. Although there
>> > > are some common authentication data formats (e.g., an OAuth2
>> > > token),
>> > > it's entirely reasonable that the authenticator has its own way of
>> > > managing authentication data.
>> > >
>> > > So, it seems to me that the authenticator needs to be the owner of
>> > > the
>> > > authentication data and store it on disk in the format that is
>> > > appropriate for it. That to me implies that the authenticator
>> > > likely
>> > > needs to handle the UI so that it can get back the data
>> > > appropriately
>> > > and do whatever is needed so that it can re-use that data on a
>> > > subsequent interaction. If the app is managing the UI, then it
>> > > would
>> > > need a way to pass back the data from the dialog to the
>> > > authenticator.
>> > > That would require the app to have detailed knowledge about the
>> > > authentication scheme, I believe.
>> >
>> > Yes, the authenticator needs to *drive* the authentication. But that
>> > doesn't necessarily mean it has to "render" it.
>> >
>> > The way the simple case would work is that there would be some
>> > standardized fields that the authenticator tells the app to ask for
>> > in
>> > a dialog, and the result is then passed back to the authenticator
>> > where it can store it or whatever, and then this happens in a
>> > sequence. So, things are driven by  the authenticator and it gets all
>> > info, and the app just renders the fields in a nice way with matching
>> > fonts/themes, correct parenting and modality, use the desktop-
>> > specific
>> > keyring for passwords, etc.
>> >
>> > In the webflow case things are a bit more difficult, as the api is
>> > much more generic. But one can imagine solutions. For example, the
>> > authenticator could set up the operation ahead of time with the
>> > server
>> > and when the operation is done go back to the server and ask for the
>> > results. Or, we could define a standard way that the webflow results
>> > gets encoded and passed to the authenticator. Or the authenticator
>> > can
>> > proxy things via itself. Clearly needs research here, someone must
>> > have done this before?
>>
>> It doesn’t seem to have been obviously mentioned so far (but apologies
>> if I missed it — I’ve only skimmed the thread), but the standard way
>> for a CLI app to do a web-based authentication process *and then get
>> data back from the web authenticator* is for it to run a simple HTTP
>> server on localhost, and pass the URI to that to the web authenticator
>> in the URI it gives to the user to open. Once the user has
>> authenticated in their web browser, the web authenticator redirects to
>> the provided localhost URI with the results of the authentication (a
>> token, or error code, etc.)
>>
>> For example:
>>
>> 1. The CLI app would print a URI looking something like
>>
>> https://flathub.org/auth/?some=arguments&callback=https%3A%2F%2Flocalhost%3A8765
>>
>> 2. The user clicks that link, it opens in their web browser and
>> authenticates them.
>>
>> 3. On success, the authentication web page redirects to
>> https://localhost:8765?token=your-shiny-token (or sends the token as
>> POST data).
>>
>> 4. The CLI server handles this request, stores the token on disk, and
>> continues the `flatpak install` operation.
>>
>> Philip
>> _______________________________________________
>> Flatpak mailing list
>> Flatpak at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/flatpak
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20191015/f379c735/attachment.html>