Closed svonworl closed 1 month ago
Attention: Patch coverage is 12.50000%
with 21 lines
in your changes are missing coverage. Please review.
Project coverage is 72.42%. Comparing base (
e6d0782
) to head (012f0f3
).
Files | Patch % | Lines |
---|---|---|
...ore/webservice/DockstoreWebserviceApplication.java | 4.76% | 20 Missing :warning: |
...java/io/dockstore/webservice/SimpleAuthorizer.java | 66.66% | 0 Missing and 1 partial :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
There doesn't appear to be direct support for roles in OpenAPI, so we would have had to map the
@RolesAllowed
annotations to the closest security-related OpenAPI analog. Certainly, all of this would have been possible, but there didn't appear to be a quick and simple way...
I guess the other idea would be to process the openapi.yaml ourselves or find some script. But this works
I added some constants to SimpleAuthorizer
and changed the code to use them, and indented each line of the message to make it less confusable with the log levels in other log messages.
Description This PR modifies the webservice to log a message that contains a list of "privileged" endpoints, which are endpoints with a
@RolesAllowed
annotation which allows one or more of theadmin
,curator
, orplatformPartner
roles. The list is logged once, at startup time.Example log excerpt:
The ticket (and ticket writer) preferred that the role information was added to our swagger UI page. This would have required us to first propagate the "admin" info from our code into
openapi.yaml
, and then to modify our Swagger UI page (which reads a public copy ofopenapi.yaml
) to render the new OpenAPI information. There doesn't appear to be direct support for roles in OpenAPI, so we would have had to map the@RolesAllowed
annotations to the closest security-related OpenAPI analog. Certainly, all of this would have been possible, but there didn't appear to be a quick and simple way...The goal was to get the auditor a list of "admin" endpoints, and although this implementation might not be 100% optimal, they should be able to work with this format.
Originally, I'd anticipated logging at
DEBUG
level, but to ensure the information makes it to CloudWatch, should we need it, I promoted the message toINFO
level. It's logged one time per run, so no big deal.The semantics which we use to combine endpoint path fragments are a bit different than typical file path semantics, thus the custom
joinPaths
method (rather than using a canned method).Review Instructions Check the webservice logs, and confirm that the new message appears, and has the correct number of endpoints listed.
Issue https://ucsc-cgl.atlassian.net/browse/SEAB-6310
Security and Privacy No concerns.
Please make sure that you've checked the following before submitting your pull request. Thanks!
mvn clean install
@RolesAllowed
annotation