diff options
| author | Douwe Maan <douwe@gitlab.com> | 2016-09-28 18:13:34 +0000 |
|---|---|---|
| committer | Douwe Maan <douwe@gitlab.com> | 2016-09-28 18:13:34 +0000 |
| commit | 029c0d79af082a7373dd89eafe2a6aeaeefc0288 (patch) | |
| tree | 00328dec2f0d284fc54c53997eabf5f92a222469 /public | |
| parent | 578488ee7e77b6f79d0341ef8da3b7afd75a2d68 (diff) | |
| parent | 2772109ac15bed2bd199294f8d770f49a749b4bd (diff) | |
| download | gitlab-ce-029c0d79af082a7373dd89eafe2a6aeaeefc0288.tar.gz | |
Merge branch 'lfs-ssh-authorization-fix' into 'master'
Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called
## What does this MR do?
Do not regenerate the `lfs_token` every time `git-lfs-authenticate` is called, instead return the saved token if one is present.
This was causing a lot of 401s, leading to 403s, as state in #22527
As it turns out, when pushing a lot of LFS objects, the LFS client was calling `git-lfs-authenticate` in the middle of the request again. This caused the `lfs_token` to be regenerated. The problem lies in that the LFS client was not aware of this change, and was still using the old token. This caused all subsequent requests to fail with a 401 error.
Since HTTP Auth is protected by Rack Attack, this 401s where immediately flagged and resulted in the IP of the user being banned.
With this change, GitLab returns the value stored in Redis, if one is present, thus if the LFS client calls `git-lfs-authenticate` again during the request, the auth header will remain unchanged, allowing all subsequent requests to continue without issues.
## What are the relevant issue numbers?
Fixes #22527
cc @SeanPackham @jacobvosmaer-gitlab
See merge request !6551
Diffstat (limited to 'public')
0 files changed, 0 insertions, 0 deletions