[research] Git client UX with giftless esp how does authentication work?

[rufuspollock]

What is UX for a git user on the command line using giftless? In particular, how does authentication work?

Tasks

• draw a sequence diagram

Analysis

We will be using http for the server e.g. https://giftless.datahub.io. Thus, this is the relevant part of https://github.com/git-lfs/git-lfs/blob/master/docs/api/authentication.md:

Git provides a credentials command [see below] for storing and retrieving credentials through a customizable credential helper. By default, it associates the credentials with a domain. You can enable credential.useHttpPath so different repository paths have different credentials.

Git ships with a really basic credential cacher that stores passwords in memory, so you don't have to enter your password frequently. However, you are encouraged to setup a custom git credential cacher, if a better one exists for your platform

This is detailing the first leg of interactions, i.e. the attempt to auth with giftless. In CKAN setup we want this to go to ckan authz api and request relevant token. In standalone giftless this is a TODO atm.

You can read more about git credentials here:
https://git-scm.com/docs/gitcredentials. Reading this it looks like you would want to configure this as follows:

[credential "https://giftless.datahub.io"]
	helper = /path/to/my/ckan/auth/utility

Then the /path/to/my/ckan/auth/utility would be something that went and got the token from CKAN.

How this token is then used by git lfs is still not totally clear - i hope it just sends it in the authorization header. See excerpt below from git-lfs/git-lfs#2330 (comment)

Research

• https://github.com/git-lfs/git-lfs/blob/master/docs/api/authentication.md - authentication docs
• https://developer.lsst.io/v/DM-6968/tools/git_lfs.html - detailed instructions on how to set up your git credentials so as to access custom git lfs storage
  • https://developer.lsst.io/v/DM-6968/tools/git_setup.html#git-credential-helper

Authentication docs

https://git-scm.com/docs/gitcredentials

git-lfs/git-lfs#2330 (comment)

By default, Git LFS will attempt to authenticate with no authentication. LFS-Authenticate is an LFS-specific version of the WWW-Authenticate header for web browsers. It is not intended to authenticate the request, but to tell Git LFS how to authenticate.

Git LFS makes request with no auth
LFS server returns 401 something like Lfs-Authenticate: Basic realm="GitHub"
Git LFS retries request with Basic authentication
Success!
Instead, it looks like your LFS server is replying information like this on each object:

"expires_in":600,
"header":{"LFS-Authenticate":"TOKEN"}
I don't know how your LFS server is written, but it should probably be sending an Authorization header. Tweak the expires_in value to an acceptable level. At 600s, LFS will re-access the batch API after 10m of running your upload or download command. It looks like LFS is confused by the incorrect usage of LFS-Authenticate. There are two things LFS looks to determine if one of those URLs is already authenticated:

It has an Authorization header. The example above only has Lfs-Authenticate.
It has the "authenticated" property enabled. Check out the uploads example in the API docs.
LFS is still sending the Lfs-Authenticate header, but it's also going through git credentials to try to get a valid login for staging.sthse.co. If you change your server to use a valid Authorization header and set the "authenticated" property, you should be good to go.

[shevron]

@rufuspollock can we close this?
Note also that Giftless now also supports piggybacking on git HTTP Basic authorization with JWT tokens: https://giftless.datopian.com/en/latest/jwt-auth-guide.html#authenticating-command-line-git-lfs