-
Notifications
You must be signed in to change notification settings - Fork 361
Reorder filters and let RealmContextResolver throw UnresolvableRealmContextException #848
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
Conversation
e542f5c to
9c45494
Compare
|
This is now ready for review. |
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 you mind moving this to a (new) method on PolarisServerManager or Server so that it is possible to customize?
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.
nit: maybe make internalCatalogName a parameter to this test?
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'm not sure about 401 in this context. I believe it generally means your credentials are not valid, which is not applicable to failures in realm resolution.
I'm thinking that a 404 may fit better. For example, GH gives 404 on accessing repositories (i.e. realms) to which the user has no access.
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.
Makes sense, i will update the PR title and description accordingly.
quarkus/service/src/main/java/org/apache/polaris/service/quarkus/config/QuarkusProducers.java
Outdated
Show resolved
Hide resolved
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 think it could be valuable to cover this with an explicit config flag. If realms are used in a particular deployment, it is probably not wise to allow potentially malicious clients to try sending requests at the default realm without knowing its 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.
I completely agree, I think that having a default realm is a potential security issue.
dimas-b
left a comment
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.
Nice improvement to request filters! Thanks, @adutra !
As far as I can tell this change is backward compatible at the REST API / HTTP level.
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.
Maybe rename to realmHeaderName() + realmId() (latter for consistency w/ Server)?
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.
| default String realmHeader() { | |
| default String realmHeaderName() { |
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.
| * <p>Note: this is actually only enforced when using {@link DefaultRealmIdResolver}. When using | |
| * {@link TestRealmIdResolver}, this setting is ignored. | |
| * <p>Note: this setting is only enforced in production setups. |
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.
Should this be true by default?
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.
Defaulting to true would be a behaviour change at the REST/HTTP level. I'd prefer to keep old behaviour in this PR and change defaults later.
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.
WFM
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.
Yeah changing this to true would break downstreams. But we can mention this in the "Configuring for production" docs.
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.
Wonder if it makes more sense to change RealmIdResolver to expect a Function<String, String> rather than a "full blown map" (and use request::getHeader here).
|
@collado-mike : any concerns from your POV? |
|
PR Rebased. @dimas-b @snazy @collado-mike can I get another review please? |
dimas-b
left a comment
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.
LGTM 👍 I found a fresh, but tangential issue, however I think we can address it later (if people agree with my proposal below).
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.
tangential: When OTel is disabled, it's still ok to operate on Span.current(), we'd simply get a "no-op" Span. However, IMHO it is preferable to exercise the code that produces span values even when tracing is disabled. This is to avoid bugs that only pop up when tracing is on.
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 get the sentiment, but at the same time, it's nice to be able to turn off the functionality entirely, including any bugs that may be present that could impact the running service even though you don't want/care about tracing.
|
This has been in review for 2 weeks. Is it OK to merge now? @collado-mike |
collado-mike
left a comment
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.
LGTM
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 get the sentiment, but at the same time, it's nice to be able to turn off the functionality entirely, including any bugs that may be present that could impact the running service even though you don't want/care about tracing.
| if (!configuration.realms().contains(realm)) { | ||
| throw new IllegalArgumentException("Unknown realm: " + realm); | ||
| throw new UnresolvableRealmContextException("Unknown realm: " + realm); | ||
| } |
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.
Personally, i would push the check down into the RealmContextConfiguration rather than exposing a set of valid realms and doing the check here. But for this change, I think the UnresolvableRealmContextExcpetion is the right change to make
Fixes #819.
Summary of changes:
ContainerRequestFilterRealmIdFilterintroducedRealmIdResolvernow can throwUnresolvableRealmException=> maps to HTTP 404PolarisApplicationIntegrationTestRealmIdFilterQuarkusLoggingMDCFilterQuarkusTracingFilterPolarisPrincipalAuthenticatorFilterPolarisPrincipalRolesProviderFilterRateLimiterFilter