You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of the abstraction [1] of SecurityRequest/SecurityResponse, changes were made for how headers were processed. OpenSearch's RestRequest object treats headers as a Map<String, List<String>> whereas in the refactor this was simplified to Map<String, String> This has caused some plugins that extend behavior of the security plugin to be broken.
SecurityResponse classes should switch to a Map<String, List<String>> representation so workarounds aren't needed in downstream consumers.
Read up on duplicate header entries and how they are handled
Confirm if a refactor is needed or if this can be done via another method (comma delimited?) StackOverflow
Update SecurityResponse from Map<String, String> headers; to Map<String, List<String>> headers;
Fix all impacted areas of the codebase
Add tests that use and verify duplicate header entries
The text was updated successfully, but these errors were encountered:
peternied
changed the title
SecurityRequest & SecurityResponse only accept single header values
SecurityResponse only accept single header values
Oct 26, 2023
LGTM,
based on stackOverflow mentioned sending multiple value as comma separated in single value means whoever extends this has to write this logic of preparing the single value separated by comma for multi value header which I feel overhead.
[Triage] Thank you for filing this issue @peternied. This looks good to go.
stephen-crawford
added
triaged
Issues labeled as 'Triaged' have been reviewed and are deemed actionable.
and removed
untriaged
Require the attention of the repository maintainers and may need to be prioritized
labels
Oct 30, 2023
As part of the abstraction [1] of SecurityRequest/SecurityResponse, changes were made for how headers were processed. OpenSearch's RestRequest object treats headers as a
Map<String, List<String>>
whereas in the refactor this was simplified toMap<String, String>
This has caused some plugins that extend behavior of the security plugin to be broken.SecurityResponse classes should switch to a
Map<String, List<String>>
representation so workarounds aren't needed in downstream consumers.Acceptance Criteria
Map<String, String> headers;
toMap<String, List<String>> headers;
The text was updated successfully, but these errors were encountered: