Geo: Fix push to secondary over SSH for LFS
What does this MR do?
This MR fixes a bug when pushing to a secondary over SSH for LFS. GitLab supports LFS authentication over SSH (despite the bulk of actions occurring over HTTP) but in the case of pushing to a secondary, the incorrect JSON auth content was returned.
When pushing over SSH to a secondary with git-lfs enabled, the JSON auth blob that is returned from POST /internal/lfs_authenticate
, contains credentials & href designed for the secondary. The fragment needs to contain credentials & href designed for the primary.
e.g.
Primary
upload
$ ssh -p 2221 -- ash@ee-secondary1.local git-lfs-authenticate root/test.git upload
{"header":{"Authorization":"Basic abc123"},"href":"https://ee-primary.local/root/test.git/info/lfs/"}
Secondary
upload
$ ssh -p 2222 -- ash@ee-secondary1.local git-lfs-authenticate root/test.git upload
{"header":{"Authorization":"Basic def456"},"href":"https://ee-secondary1.local/root/test.git/info/lfs/"}
It's also worth noting, that when downloading LFS objects, we should still return the secondary URL to keep the operation as fast as possible:
download
$ ssh -p 2222 -- ash@ee-secondary1.local git-lfs-authenticate root/test.git download
{"header":{"Authorization":"Basic def456"},"href":"https://ee-secondary1.local/root/test.git/info/lfs/"}
To work correctly, the secondary must return the same JSON auth payload as the primary. To achieve this, the GitLab::LfsToken#token
logic needed to be changed from using a random string (Devise.friendly_token(50)
) to use JSONWebToken::HMACToken
, based on either the last 16 characters of the user's encrypted password or the first 16 characters of the deploy key / key fingerprint.
I also added missing specs which now brings the coverage up to 100% :)
What are the relevant issue numbers?
https://gitlab.com/gitlab-org/gitlab-ee/issues/8114
Does this MR meet the acceptance criteria?
-
Changelog entry added, if necessary [ ] Documentation created/updated-
Tests added for this feature/bug -
Conforms to the code review guidelines -
Conforms to the merge request performance guidelines -
Conforms to the style guides [ ] Conforms to the database guides-
EE specific content should be in the top level /ee
folder [ ] For a paid feature, have we considered GitLab.com plans, how it works for groups, and is there a design for promoting it to users who aren't on the correct plan?