Research for app purchases

Tue Oct 15 15:33:07 UTC 2019

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/8aeccf37/attachment-0001.html>