Use CI_PROJECT_ID instead of name of the project in API calls

[gaborauth]

Use CI_PROJECT_ID instead of name of the project in API calls

[fgreinacher]

It's not a bug, it's looks like a valid security setting

Oh thanks, I was not aware of this. Not really a standard thing, but still somewhat common it seems: https://stackoverflow.com/questions/5942780/why-is-it-a-security-risk-to-allow-encoded-slashes-in-a-uri

Okay, last question: what would be the disadvantage if the plugin sends to the Gitlab's API the CI_PROJECT_ID instead of the CI_PROJECT_PATH?

Good question! There might be edge cases where folks set CI_PROJECT_PATH explicitly that could then break.

Now it just depends what is more common - folks that have proxies messing with the URL, or folks that set CI_PROJECT_PATH... 🤔

I'd tend to say we can switch to CI_PROJECT_ID but I'd like to hear opinions from other maintainers before proceeding, WDYT @travi @gr2m?

[fgreinacher]

I don't really know gitlab but your based on the discussion the suggestion sounds good to me 👍🏼

Thanks, then let's do it: #576

[feefladder]

Having the same issue, any idea how to fix?

[fgreinacher]

Hm, this sounds more like a problem on your end.

Accessing the API via project path works if the path is properly URL-encoded. This is the case for semantic-release, but not in your curl invocation.

I guess you're having authentication issues. Did you follow https://semantic-release.gitbook.io/semantic-release/v/beta/usage/ci-configuration#push-access-to-the-remote-repository?

[gaborauth]

Hm, this sounds more like a problem on your end. Accessing the API via project path works if the path is properly URL-encoded. This is the case for semantic-release, but not in your curl invocation.

I went around the problem and looks like the encoded slash ('/' to '%2F') in the URL before the first query parameter is replaced to %252F by security reason in the firewall we are using and the Gitlab cannot process it:
"GET /api/v4/projects/others%252Ftoolsforboox%252Ftoolsboox-backend HTTP/1.1"

Otherwise, it would look like this:
"GET /api/v4/projects/others%2Ftoolsforboox%2Ftoolsboox-backend HTTP/1.1"

In case of CI_PROJECT_ID works without an issue:
"GET /api/v4/projects/12 HTTP/1.1"

I guess you're having authentication issues.

The authentication is fine, the CI_PROJECT_ID based API access is works.

--

Could it be possible to access the Gitlab's API based on the project id instead of the project path? Change the settings of the company's firewall is virtually impossible in my end of the issue... :)

Edit: the other option would be, to have Gitlab process both %2F and %252F encodings. I try to raise a ticket about it.

[fgreinacher]

I went around the problem and looks like the encoded slash ('/' to '%2F') in the URL before the first query parameter is replaced to %252F by security reason in the firewall we are using and the Gitlab cannot process it:
"GET /api/v4/projects/others%252Ftoolsforboox%252Ftoolsboox-backend HTTP/1.1"

This sounds like a bug in your Firewall, %252F is the encoded variant of %2F, which is
incorrect.

You can hack around this by overriding CI_PROJECT_PATH with $CI_PROJECT_ID before running semantic-release. I'd prefer to not introduce new configuration options to keep complexity as low as possible.

[gaborauth]

This sounds like a bug in your Firewall, %252F is the encoded variant of %2F, which is incorrect.

It's not a bug, it's looks like a valid security setting, prevents some of double encoding attacks, but it is not my cup of tea, I cannot change this behavior.

You can hack around this by overriding CI_PROJECT_PATH by CI_PROJECT_ID before running semantic-release.

Okay, I try it, but I think it may have side effects...

I'd prefer to not introduce new configuration options to keep complexity as low as possible.

Okay, last question: what would be the disadvantage if the plugin sends to the Gitlab's API the CI_PROJECT_ID instead of the CI_PROJECT_PATH?

[gr2m]

I don't really know gitlab but your based on the discussion the suggestion sounds good to me 👍🏼

[travi]

sorry for the delay. returned recently from traveling. i'm also pretty unfamiliar with gitlab, so i support the decision to avoid the problem here.

the one thought that i do want to put out there is that this is a chance to step back to consider if we are doing something wrong at a higher level.

It's not a bug, it's looks like a valid security setting, prevents some of double encoding attacks

i havent given this a ton of thought, but my initial reaction is similar to @fgreinacher's that is a firewall config bug if it is rewriting content in ways that breaks things like this. it would take a bit more evidence to convince me otherwise if we didnt have an alternative like the approach taken to solve this. however, i'm totally open to the evidence supporting that we were doing something wrong with our encoding. it is great that we had an alternative to avoid the issue for this situation, but i'm still concerned about whether that same approach is used elsewhere that will result in other complications. is it worth understanding this a bit deeper to get some insight into whether we have other issues that we should address?