GitLab Authentication about velocita-proxy HOT 17 CLOSED

Yeah sounds like that'd cause some issues as well, for sure. But I also discovered that no GitLab response was ever cached because of the headers they send back, so it's a two-fer-one!

from velocita-proxy.

Good idea! I just found the problem. Firewall... For some reason, the firewall analysed outgoing packets.

It works now with the bearer token! Thanks for your help and sorry for the firewall inconvenience!

from velocita-proxy.

Hi @Tiippex,

The following works for me:

curl --user 'username:personal-access-token' -X GET https://gitlab.com/api/v4/group/12345/-/packages/composer/packages

Are you 100% sure that you are using the right username and associated personal access token?

from velocita-proxy.

Hey,

thats quite funny. Yes, the credentials are correct. I was able to open the URL you provided with our group ID but I can't open the URL which is located in the access logs:
https://gitlab.com/api/v4/projects/GROUP%SUBGROUP/repository/archive.zip?sha=WHATEVERHASH

This results in a 404 when I use basic auth. The header/gitlab sessions results in a file

from velocita-proxy.

The following also works for me:

curl --verbose \
    --user 'username:personal-access-token' \
    -X GET \
    'https://gitlab.com/api/v4/projects/1234/packages/composer/archives/composer-test.zip?sha=cafe1234beef' \
    --output composer-test.zip

So there's definitely something funky going on with the way the package is being retrieved. Can you provide the logs Velocita Proxy produces around when the package is being retrieved?

That being said, GitLab provides three ways of authenticating with a personal access token, and basic authentication is not one of them. It's probably a good idea to add support for both bearer tokens and custom headers in general.

from velocita-proxy.

Hi @Tiippex,

Can you try out Velocita Proxy v3.6.0 and use authentication type bearer with just the password set to the personal access token you use?

from velocita-proxy.

Hey @gmta,
I was able to locate the issue. Some of our colleagues used the repository type "vcs" instead of "composer".

This is the cause for the https://gitlab.com/api/v4/projects/* URLs in the composer.lock file.
I guess that only the https://gitlab.com/api/v4/projects/1234/packages/composer/* URLs allow basic authentication.

I'm going to set up an instance with the new version and will give you feedback soon! Thanks for the fast fix.

from velocita-proxy.

Doesn't work for me so far. I get a 401 from the nginx.

What I have done:
Changed auth type from basic to bearer
Created a new group token with developer role and API permission
Set the token as the password
Removed the username variable
composer install

I have tried opening the URL by hand passing the &private_token=XYZ by hand. That worked for me. So I can say that the permissions and the role should work.

from velocita-proxy.

Hm, according to GitLab group tokens are not explicitly supported:
https://docs.gitlab.com/ee/user/packages/composer_repository/#install-a-composer-package

One of the following token types:

• A personal access token with the scope set to, at minimum, api.
• A deploy token with the scope set to read_package_registry, write_package_registry, or both.

Could you please try again with a PAT or deploy token?

from velocita-proxy.

I still get the same error:

from velocita-proxy.

@Tiippex can you share your anonymized Velocita .env / environment variables please?

from velocita-proxy.

from velocita-proxy.

You should set MIRROR_GITLAB_TYPE=composer since you're mirroring a Composer repository, but the other settings seem OK. Just to be sure, can you remove the GitLab cache before trying again? rm -rf /path/to/var/cache/velocita/gitlab

And can you then paste the Velocita Proxy logs of the request here? There should be at least two, your incoming request and the upstream request logs.

from velocita-proxy.

Sure!
I changed the type to composer. I noticed some 404 errors and one 401 error. 401 is caused by a /packages/composer URL and the 404 by the /repository/archive URL.

https://paste.tiippex.de/3belsLx70P4prtKS9zuEj2

from velocita-proxy.

Let's compare with a successful run by me:

172.21.0.1 - - [19/Jan/2023:12:02:54 +0000] "GET /mirror/gitlab/api/v4/projects/1234/packages/composer/archives/vendor/package.zip?sha=HASH HTTP/1.1" 200 3653 "-" "Composer/2.5.1 (Linux; 5.19.0-29-generic; PHP 8.2.1; cURL 7.87.0)" "-"
172.21.0.1 - - [19/Jan/2023:12:02:54 +0000] upstream gitlab.com 172.65.251.78:443 [MISS] GET /mirror/gitlab/api/v4/projects/1234/packages/composer/archives/vendor/package.zip?sha=HASH HTTP/1.1 [200] 1.914ms 3667b

Some differences I see:

• Your gitlab.com upstream IP is 0.0.0.0 which is not correct. Or did you anonymize it?
• You are running on PHP 7.3 which is no longer supported
• Your Composer is sending HTTP/1.0 requests while mine is sending out HTTP/1.1

Can you please check with newer versions of PHP and Composer to see if the issue is version-related?

from velocita-proxy.

Your gitlab.com upstream IP is 0.0.0.0 which is not correct. Or did you anonymize it?
that was me

You are running on PHP 7.3 which is no longer supported
oops. My bad, but I get the same issue with 8.1 D:

Still sending 1.0 requests. Might be firewall related.

from velocita-proxy.

Looking at your config, you probably have a reverse proxy in front of Velocita, correct? Can you try communicating directly with Velocita?

from velocita-proxy.