Using flat-manager for private app repo

[Robert McQueen]

Oops, crossed mails. You can broadly ignore my previous one. :)

On Fri, 2019-05-03 at 07:15 -0500, Dan Nicholson wrote:
> On Fri, May 3, 2019 at 3:44 AM Alexander Larsson <alexl at redhat.com>
> wrote:
> > We do however need to know this. But I don't think you ever need
> > this
> > full list? Instead what the client does is look at the summary
> > file,
> > figures out which commit and delta uris to download, and then just
> > does it, passing in the token the auth server gave it (for this
> > ref)
> > to every such request. Then the CDN/flat-manager needs to know if
> > this
> > particular ref requires a token, and if so which token.

I think what the client needs to know is similar but slightly different
- "will the auth server give me a token for this" - ie should the
button be "Buy" or "Donate" or whatever vs "Download".

> > 2) Split free and for-pay refs into different repos and apply token
> > requirements to all downloads in the for-pay repo.
> > 
> > The alternative to 2 is to mark up each ref somehow, but it seems
> > easier both from a server side and client side (you need to figure
> > out
> > when you need to request a token) to have this be a global option
> > per
> > repo.
> 
> Yep, that's pretty much what I had in mind. I think there's a way to
> make the existing prefixes work, but the globbing (or a regex) would
> be more flexible. I also thought there could be a way to maintain
> free
> refs in the same repo if flat-manager knew which refs were free. Then
> it could skip the token check for those refs. But I don't know
> exactly
> how and where you'd define that, so I decided it would be simpler to
> start by requiring that the repo is either public or private and all
> commit access in the latter requires a token that specifies the
> allowed refs.

I think it makes sense that we could add an API server to the
configuration for the remote, which the client can talk to, and this
signals that a token from this server is necessary for any fetch. Then
libflatpak can also talk to this server in order to answer the above
question of what tokens might be available.

> > 4) Research into various CDN configurations
> 
> As mentioned above, I think this would be tricky, but I'm sure
> there's
> a way. In the absence of configuring authentication at the CDN, then
> I
> think flat-manager needs to set the Cache-Control header to no-store
> on commit objects and delta superblocks so that if there is a CDN in
> front of it that it doesn't start serving a cached version to anyone
> that comes along.

I think it's a bit easier, you can return the name of the token header
in the Vary: field of the response. That means the CDN should include
the value of that field in what it caches for the request. Ie a request
with the same token can be served from the cache, but a request with a
different token shouldn't be cached the same way.

> 
> > Most of this looks relatively simple actually. The most problematic
> > part is probably going to be the API to the authentication server.
> > In
> > particular how you authenticate to that. The details of this
> > authentication is likely to be different for every repo provider
> > (user
> > + password, email + password, api token, etc) and the secret will
> > have
> > to be stored somewhere in the flatpak configuration, or provided in
> > some secure way. This must both be flexible and secure, which is a
> > hard combination.
> 
> Totally agree that the server side is actually fairly simple (besides
> the CDN integration), but the client side will be more challenging.
> I've thought about it a few times, but I haven't come up with much.
> That said, this really isn't any different than using a 3rd party
> online identity provider. Maybe we should look at how GOA does it. At
> least for how to talk to the auth server and how to store the secrets
> locally.

Yeah from Flatpak's perspective you need a GOA or similar - something
has to just hand liblatpak the user token for the repo, and then it's
eg GNOME Software that bounces you through OAuth or SAML whatever to
get the whole party started. (or some other platform-specific
integration code)

> --
> Dan

Cheers,
Rob

> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>