This isn't particularly important, I primarily just wanted a discussion to link to locally and might be missing something.

I'm getting an unwanted credential prompt from LFS during git checkout on a custom server implementation. Here's an example trace:

$ GIT_TRACE=1 git checkout master
05:42:18.070132 git.c:348               trace: built-in: git 'checkout' 'master'
05:42:18.155243 run-command.c:335       trace: run_command: 'git-lfs smudge -- '\''lfs/a.png'\'''
05:42:18.155742 run-command.c:195       trace: exec: '/bin/sh' '-c' 'git-lfs smudge -- '\''lfs/a.png'\''' 'git-lfs smudge -- '\''lfs/a.png'\'''
trace git-lfs: run_command: 'git' config -l
Downloading lfs/a.png (2 B)
trace git-lfs: ssh: local@localvault.phacility.com git-lfs-authenticate diffusion/18/poems.git download 
trace git-lfs: api: batch 1 files
trace git-lfs: HTTP: POST http://local.phacility.com/diffusion/POEMS/poems.git/info/lfs/objects/batch
trace git-lfs: HTTP: 200
trace git-lfs: HTTP: {"objects":[{"oid":"87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7","size":2,"actions":{"download":{"href":"http:\/\/local.phacility.com\/file\/data\/@local\/v6a6ay4z4b6wbezzl5w6\/PHID-FILE-dzezfqdr2zbyplh4u4pr\/awys4t3u7eccyoih\/lfs-87428fc522803d31065e7bce3cf03fe475096631e5e07bbd7a0fde60c4cf25c7"}}}]}
trace git-lfs: HTTP: 
Username for 'http://local.phacility.com': 

Here's why, as far as I can determine:

skipCredsCheck() decides that a file content request does not require credentials if there is an Authorization header or a query parameter named token, presumably because this is what S3 uses.

I think this means that if you have a server which uses the URL path itself or some query parameter other than token for access control, git-lfs may prompt you during checkout to provide credentials which do not exist.

(I'm hitting this locally with an SSH + git-lfs-authenticate workflow, so git doesn't do any earlier HTTP activity on its own, and I use part of the URL path instead of in a query parameter to authenticate access.)

The server can work around this by providing a dummy Authorization header (or, presumably, a dummy token query parameter), so this isn't much of an issue, but "dig through the source to determine that token is magic", while quite practical, probably isn't ideal. I added an Authorization: Basic quackquackquack sort of header to the response and that appears to have resolved the issue locally.

I couldn't find a description of this in the documentation and it looks like it was introduced in 228bea7, which is light on context and might be an "unbreak production" kind of change.

Some possible approaches I can imagine:

• Maybe not worth fixing?
• Document that token is magic and leave it at that?
• Add an explicit "authentication": "none, trust me" property to the object response?
• If we don't have credentials from any source which doesn't require prompting, send a request and wait for a 401 before prompting? This is the behavior I would naively expect, but maybe there are reasons that it won't work well.

I might also be doing something else wrong to get myself into this mess in the first place.