Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Download of suppression files with authorization header #5783

Open
amohrig-kn opened this issue Jun 20, 2023 · 3 comments · May be fixed by #7268
Open

Download of suppression files with authorization header #5783

amohrig-kn opened this issue Jun 20, 2023 · 3 comments · May be fixed by #7268

Comments

@amohrig-kn
Copy link

Is your feature request related to a problem? Please describe.

We are keeping some of our suppression files in our company internal on-premise version control system, and so far have been using simple URLs for referencing and downloading them during the analysis. This is possible as long as the repository allows public access.

For security reasons we would like to disable all public access even to our internal repositories, though. At the moment it is possible to achieve a retrieval of a suppression file even in that case using username and password, but managing a complete user with credentials is cumbersome just for retrieval of a suppression file.

Our version control system offers the creation of access tokens for repositories, which can then be used in an authorization header to access repository content. This allows to create individual tokens per integration, which is also the recommended way.

Describe the solution you'd like

It would be nice if the utils for downloading suppression files (and the configuration they use) could support either an 'Authorization: Bearer' header or completely freely configurable extra-headers.

I may be able to implement this and create a pull-request if we can align on the functional solution.

Describe alternatives you've considered

  • using basic auth with username and password: possible already, but cumbersome in our case
  • encoding credentials into the URL somehow: unexpected and somewhat "hacky"

Additional context
(none)

@jeremylong
Copy link
Owner

I am okay with adding an option to use an authorization token. I wouldn't explicitly make it a bearer token - but allow the user to specify the value for the authorization header instead of only using the username/password. It would be great if you could create a PR or it might be a while before you see this implemented.

@amohrig-kn
Copy link
Author

Thanks for the quick reply! I will try to make some time for it soon.

@ftiercelin
Copy link
Contributor

ftiercelin commented Dec 16, 2024

@jeremylong were you thinking of something like

<suppressionAuthorizationHeader>Bearer eyJhbGciOiJIUzI1NiI...MDIySMeKKF2yJV_adQssw5c</suppressionAuthorizationHeader>

or even <suppressionAuthorizationHeader>Basic dGhlX3VzZXI6dGhlX3Bhc3N3b3Jk</suppressionAuthorizationHeader> for a basic auth

... and are you still interested by a PR to address this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants