<div dir="ltr"><div><br></div><div>Related to my previous email, this could be the workflow for flatpak purchases</div><div><br></div><div><br></div><div><font size="2"><span style="font-family:monospace"># Login to flathub remote and store credentials (token) locally<br></span></font></div><div><font size="2"><span style="font-family:monospace">flatpak remote-login flathub<br> <a href="mailto:Username%3Aemail@example.com">Username:email@example.com</a><br> Password:*******<br></span></font></div><div><br></div><div><font size="2"><span style="font-family:monospace"># Install free (as a bier) app<br></span></font></div><div><font size="2"><span style="font-family:monospace">flatpak install flathub org.gnome.Polari</span></font></div><div><font size="2"><span style="font-family:monospace"> (Normal installation)<br></span></font></div><div><font size="2"><span style="font-family:monospace"><br></span></font></div><div><font size="2"><span style="font-family:monospace"># Install app that I have purchased previously<br>flatpak install flathub com.exemple.AppThatRequiresPaymentPreviouslyBought<br> (Normal installation)<br></span></font></div><div><font size="2"><span style="font-family:monospace"><br></span></font></div><div><font size="2"><span style="font-family:monospace"># Install app that I need to purchase<br>flatpak install flathub com.exemple.AppThatRequiresPayment<br> Error: this app requires purchase. Please go to <a href="https://flathub.org/apps/com.exemple.AppThatRequiresPayment">https://flathub.org/apps/com.exemple.AppThatRequiresPayment</a> <br> or use gnome-software or another compatible client to complete purchase<br></span></font></div><div><font size="2"><span style="font-family:monospace"><br></span></font></div><div><font size="2"><span style="font-family:monospace"># List all my purchases at flathub<br>flatpak remote-ls-purchases flathub<br></span></font></div><div><font size="2"><span style="font-family:monospace"><br></span></font></div><div><font size="2"><span style="font-family:monospace"># Logout (clear credentials)<br>flatpak remote-logout flathub<br></span></font></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Missatge de Jorge García <<a href="mailto:jgarciao@gmail.com">jgarciao@gmail.com</a>> del dia dt., 15 d’oct. 2019 a les 17:33:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div></div><div></div><div>Hi,</div><div><br></div><div>> 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<br>> server on localhost, and pass the URI to that to the web authenticator</div><div><br></div><div>Docker uses another way to authenticate to registry servers like Docker Hub:</div><div>1) The user creates an account via web browser at <a href="https://hub.docker.com" target="_blank">https://hub.docker.com</a>, obtaining a username and password<br></div><div>2) On the command line, the user executes "docker login" and enters username and password<br></div><div>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 <a href="https://docs.docker.com/engine/reference/commandline/login/" target="_blank">here </a><br></div><div>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<br></div><div>5) docker logout removes the token from the store</div><div></div><div><br></div><div>This is explained (much better) here:</div><div>- <a href="https://docs.docker.com/engine/reference/commandline/login/" target="_blank">https://docs.docker.com/engine/reference/commandline/login/</a></div><div>- <a href="https://docs.docker.com/registry/spec/auth/token/" target="_blank">https://docs.docker.com/registry/spec/auth/token/</a></div><div><br></div><div>Regards,</div><div>Jorge<br></div><div></div><div><br></div><div><br></div><div><br></div><div><br></div><div><code><br></code></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Missatge de Philip Withnall <<a href="mailto:philip@tecnocode.co.uk" target="_blank">philip@tecnocode.co.uk</a>> del dia dt., 15 d’oct. 2019 a les 17:15:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fri, 2019-10-11 at 10:02 +0200, Alexander Larsson wrote:<br>
> On Thu, Oct 10, 2019 at 8:01 PM Dan Nicholson <<a href="mailto:nicholson@endlessm.com" target="_blank">nicholson@endlessm.com</a><br>
> > wrote:<br>
> > On Fri, Oct 4, 2019 at 3:28 AM Alexander Larsson <<a href="mailto:alexl@redhat.com" target="_blank">alexl@redhat.com</a>><br>
> > wrote:<br>
> > > I'm leaning towards model 2 for the authentication, although<br>
> > > we're going<br>
> > > to require a fully generic web flow for the actual purchase part.<br>
> > <br>
> > I am far from the expert on designing this part of the interaction.<br>
> > One thing I worry about, though, is that authentication scheme and<br>
> > data is inherently specific to the authenticator. That's why we<br>
> > specified the authenticator as a separate component. Although there<br>
> > are some common authentication data formats (e.g., an OAuth2<br>
> > token),<br>
> > it's entirely reasonable that the authenticator has its own way of<br>
> > managing authentication data.<br>
> > <br>
> > So, it seems to me that the authenticator needs to be the owner of<br>
> > the<br>
> > authentication data and store it on disk in the format that is<br>
> > appropriate for it. That to me implies that the authenticator<br>
> > likely<br>
> > needs to handle the UI so that it can get back the data<br>
> > appropriately<br>
> > and do whatever is needed so that it can re-use that data on a<br>
> > subsequent interaction. If the app is managing the UI, then it<br>
> > would<br>
> > need a way to pass back the data from the dialog to the<br>
> > authenticator.<br>
> > That would require the app to have detailed knowledge about the<br>
> > authentication scheme, I believe.<br>
> <br>
> Yes, the authenticator needs to *drive* the authentication. But that<br>
> doesn't necessarily mean it has to "render" it.<br>
> <br>
> The way the simple case would work is that there would be some<br>
> standardized fields that the authenticator tells the app to ask for<br>
> in<br>
> a dialog, and the result is then passed back to the authenticator<br>
> where it can store it or whatever, and then this happens in a<br>
> sequence. So, things are driven by the authenticator and it gets all<br>
> info, and the app just renders the fields in a nice way with matching<br>
> fonts/themes, correct parenting and modality, use the desktop-<br>
> specific<br>
> keyring for passwords, etc.<br>
> <br>
> In the webflow case things are a bit more difficult, as the api is<br>
> much more generic. But one can imagine solutions. For example, the<br>
> authenticator could set up the operation ahead of time with the<br>
> server<br>
> and when the operation is done go back to the server and ask for the<br>
> results. Or, we could define a standard way that the webflow results<br>
> gets encoded and passed to the authenticator. Or the authenticator<br>
> can<br>
> proxy things via itself. Clearly needs research here, someone must<br>
> have done this before?<br>
<br>
It doesn’t seem to have been obviously mentioned so far (but apologies<br>
if I missed it — I’ve only skimmed the thread), but the standard way<br>
for a CLI app to do a web-based authentication process *and then get<br>
data back from the web authenticator* is for it to run a simple HTTP<br>
server on localhost, and pass the URI to that to the web authenticator<br>
in the URI it gives to the user to open. Once the user has<br>
authenticated in their web browser, the web authenticator redirects to<br>
the provided localhost URI with the results of the authentication (a<br>
token, or error code, etc.)<br>
<br>
For example:<br>
<br>
1. The CLI app would print a URI looking something like<br>
<a href="https://flathub.org/auth/?some=arguments&callback=https%3A%2F%2Flocalhost%3A8765" rel="noreferrer" target="_blank">https://flathub.org/auth/?some=arguments&callback=https%3A%2F%2Flocalhost%3A8765</a><br>
<br>
2. The user clicks that link, it opens in their web browser and<br>
authenticates them.<br>
<br>
3. On success, the authentication web page redirects to <br>
<a href="https://localhost:8765?token=your-shiny-token" rel="noreferrer" target="_blank">https://localhost:8765?token=your-shiny-token</a> (or sends the token as<br>
POST data).<br>
<br>
4. The CLI server handles this request, stores the token on disk, and<br>
continues the `flatpak install` operation.<br>
<br>
Philip<br>
_______________________________________________<br>
Flatpak mailing list<br>
<a href="mailto:Flatpak@lists.freedesktop.org" target="_blank">Flatpak@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/flatpak</a></blockquote></div>
</blockquote></div>