search

container-registry / backstage-plugin-harbor-backend

MIT License
5 stars 18 forks source link

fix vulnerabiliies header and update tag display #109

Closed kamroy closed 9 months ago

Vad1mo commented 1 year ago

thank you for your contribution, it seems like there is now a conflict with the contribution #108 from @StephenRobin. There is also another PR #110 by @locomoco28.

I would greatly appreciate it If you could sort that out, I am happy to accept any working solution.

sonarcloud[bot] commented 1 year ago

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

locomoco28 commented 11 months ago

@Vad1mo this PR switches from the harbor+json MIME type to security.vulnerability but the logic is based on the harbor+json MIME type.

This PR would fail. The response for the security.vulnerability does not have the keys like vulnerabilities.

https://github.com/container-registry/backstage-plugin-harbor-backend/pull/109/files#diff-dd0a57cec23efa084ec6ed775a1b92606a9fca0abc0cd69f1776ddd9113a2ec5R82

As I stated in my PR , harbor responds only with the application/vnd.security.vulnerability.report; version=1.1 MIME type. We would have to add the X-Accept-Vulnerabilities request header to the vulnerabilities fetch

https://github.com/container-registry/backstage-plugin-harbor-backend/pull/109/files#diff-dd0a57cec23efa084ec6ed775a1b92606a9fca0abc0cd69f1776ddd9113a2ec5R54

I would suggest to use my PR as it is able to handle both possible MIME types in case harbor decides to deprecate their JSON MIME type. It also uses one fetch rather than two.