DependencyTrack
Link to project page by name and version
Thanks for the PR.
All links including clicking on a component or vulnerability no longer work due to the the additional path in the URL.
Examples: http://localhost:8081/projects/components/8d037fa4-57cc-4fe9-a5ef-d21c6fb8c90a http://localhost:8081/projects/vulnerabilities/NVD/CVE-2010-5321
Both of these are invalid. I would recommend changing the logic when performing the name/version lookup that upon a successful lookup, to replace the /projects/name/version with /projects/uuid. That way, all existing logic to construct links continues to work.
Well, the existing logic to construct links was the actual problem. I missed them because I was searching for references to the router but did not found them. Now the router is used to resolve all links by using the name of the route.
@sephiroth-j, is this PR still something that you want to see merged?
If so, when resolving conflicts, remember that commits must now be signed. I think that DCO checks on PRs was enabled since you submitted this PR.
@msymons , thanks for the reminder. I would like to know if named routes should not be used at all and the redirect approach should be used. The router with it's named routes has, for example, the benefit that query and path arguments gets url-encoded by default. Named routes can be maintained at a central place and there is not struggle with (wrong) relative paths when using the router with named routes. Depending on this decision, I would discard this PR and create a new one that just includes the redirect.
p.s. Relative paths are still error prone, see #417 . Same for url-encoding.