Skip to content
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

Alternative solution for tracking unconsumed parameters #22

Merged
merged 2 commits into from
Feb 21, 2024

Conversation

peternied
Copy link

Description

Alternative solution for tracking unconsumed parameters

Testing

./gradlew integrationTest --tests org.opensearch.security.http.JwtAuthenticationWithUrlParamTests

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.


public Set<String> getConsumedParams() {
return consumedParams;
public Set<String> getUnconsumedParams() {
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this method remain as getConsumedParams()? The method returns the keys that have been accessed.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ran into this when thinking about the interface - I think parameters are either unconsumed and consumed; furthermore unconsumed parameters need to be consumed by something. This makes the overall design to transition parameters from accessed -> unconsumed -> consumed.

Since OpenSearchRequest has a way to consume parameters, returning an empty set is correct, whereas if it was accessed or consumed parameters it would return a list to be actioned on - which isn't needed.

I'd prefer the new name, but don't want to hold up your on this topic. What do you think about this?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes the overall design to transition parameters from accessed -> unconsumed -> consumed

I see what you are saying. I'm getting confused since it clashes with the RestRequest object where these are referred to as consumed params, but in this case they are accessed in the header verifier, but finally consumed in the SecurityRestFilter. I wonder if we should refer to them as accessed params to avoid a naming clash, but I see what you mean now.

@peternied peternied merged commit b0b354c into cwperks:fix-jwt-url-param Feb 21, 2024
76 checks passed
@peternied peternied deleted the fix-jwt-url-param branch February 21, 2024 23:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants