-
Notifications
You must be signed in to change notification settings - Fork 41
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
update submission received event and delete v1 azure events #15990
update submission received event and delete v1 azure events #15990
Conversation
Dependency Review✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.OpenSSF Scorecard
Scanned Manifest Files |
| mv-expand conditions | ||
| extend conditionDisplay = tostring(conditions.display) | ||
| where name == "ITEM_ACCEPTED" | ||
| extend conditionDisplay = tostring(parse_json(tostring(parse_json(tostring(parse_json(tostring(parse_json(tostring(parse_json(tostring(customDimensions.params)).bundleDigest)).observationSummaries))[0].testSummary))[0].conditions))[0].display) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there has to be a better way 😆
If it works, it works though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just used the UI in azure to extend on that field and that's what it gave me. I agree it looks kinda messy though
blobUrl = blobClient.blobUrl | ||
requestParameters = SubmissionDetails( | ||
filterHeaders(headers), | ||
filterQueryParameters(request.parameterMap.mapValues { it.value.joinToString(",") }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would we break these headers back apart in the KQL query?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand. Those two filter functions return maps of the headers and parameters so that they are separated for querying
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if we have the query string ?param=a¶m=b¶m=c
then your code will serialize it to:
mapOf(
"param" to "a,b,c"
)
So then say we want to look for all events where param
contains b
we would have to break out "a,b,c" in KQL.
My suggestion is make the fields in SubmissionDetails
to Map<String, List<String>>
and let jackson do the serialization work so its easier to parse it back to json in KQL.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I set it up to account for a single query parameter to have multiple values. I did not set it up for headers though as I don't see a use case for that yet. I also think it's a little out of scope for this ticket as I would need to update the queue message then also update the FHIRReceiver to account for the new type. If we ever actually need to accept query parameters we'd also need to do the same.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
works for me.
@@ -237,6 +247,11 @@ class SubmissionController( | |||
return headers.filter { it.key.lowercase() in headersToInclude } | |||
} | |||
|
|||
private fun filterQueryParameters(queryParameters: Map<String, String>): Map<String, String> { | |||
val headersToInclude = emptyList<String>() // update this list as new QueryParameters are needed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be moved to configuration.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same with headers as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moved both to configuration based filtering. Really good call here!
Quality Gate passedIssues Measures |
|
||
# Allowed headers | ||
allowed.headers.client_id=client_id |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Few things:
This being a map doesn't seem to serve a purpose since both key/value are the same(ish) and you ignore the key in code anyway. In code the type should just be List<String>
.
I think adding an additional prefix would help clarify the configuration as well. Something like event.allowed.headers
?
Last bit is I think yml really simplifies this file over a properties file. Here's what the result would look like:
event.allowed:
headers:
- client_id
- content-type
- payloadname
- x-azure-clientip
- content-length
queryParameters:
- ???
With a properties file there is much more duplication and you need to add indices.
event.allowed.headers[0]=client_id
event.allowed.headers[1]=content-type
...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it fixed like this. I did leave it as just allowed
since this list is also used to filter out parameters for the queue message
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Thanks for bearing with me over the config stuff. Sets us up nicely for down the road.
* A list of allowed HTTP headers that can be accepted by the API. | ||
* Each entry in the list represents a header name expected in the incoming request. | ||
*/ | ||
var headers: List<String> = emptyList() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This shouldn't be empty, right? Only queryParams for now? Off the top of my head, payloadName should be supported, along with a few others?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the field that holds the injected list of allowable header. It's defaulted to an empty list so that if someone in the future wants to allow all headers then they can. The list of allowable headers, including payloadName, is in the application.yml
file.
This PR deletes the v1 azure event data classes and improves the event emitted from the submission controller. It now includes queryParamters, httpMethod, and full request url.
Test Steps:
./gradlew bootRun
to make sure it compilesChanges
Checklist
Testing
./prime test
or./gradlew testSmoke
against local Docker ReportStream container?Linked Issues