-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
#7552 Allow adding a custom context for path management #9820
Conversation
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 will be a breaking change.
not sure this makes sense to be honest. There should be a separate context path setting for endpoints in which case it wouldn't be breaking |
To make this non-breaking IMO we should support |
I will try to update MR over the weekend by adding this property. |
I apologize, but due to Black Friday I had to work on the weekend and was unable to make the necessary changes, I will try to make it as soon as possible |
f5c5b39
to
9d3cc40
Compare
@sdelamo I made the changes based on the comments made and instead of changing the behavior of endpoints.all.path the idea is to add the endpoints.all.context-path property, I am finishing the implementation, but I came across a difficulty that I still haven't been able to overcome, for some reason when adding the new property the EndpointsFilter filter is never executed, I'm investigating this and as soon as possible I'll add the documentation and remove the draft PR. If you have any idea why a filter with the /** pattern is not filtering a request after adding a path, the tip would be very welcome. |
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.
Can you add a controller to the test to verify the controller is still accessible in the expected path?
Moreover, can you modify your test to test an endpoint which does not return 401. The Unauthorized makes the test confusing.
management/src/main/java/io/micronaut/management/endpoint/EndpointDefaultConfiguration.java
Show resolved
Hide resolved
management/src/main/java/io/micronaut/management/endpoint/EndpointDefaultConfiguration.java
Outdated
Show resolved
Hide resolved
management/src/main/java/io/micronaut/management/endpoint/EndpointDefaultConfiguration.java
Show resolved
Hide resolved
.../src/main/java/io/micronaut/management/endpoint/processors/AbstractEndpointRouteBuilder.java
Outdated
Show resolved
Hide resolved
can you merge 4.3.x against your branch. I changed the base to be 4.3.x |
As the test refers to the context path of the management endpoints and they are configured as sensitive by default, I have to guarantee that even with the change in context there is no change in the security model that the framework adds today, which is why I am following the applied testing model in the EndpointsBasePathSpec test which has a very similar objective, I still haven't been able to define why the security tests aren't passing, it's as if there was some trigger to activate the EndpointsFilter that I can't see |
@sdelamo The problem currently is that when defining micronaut.server.context-path and endpoints.all.context-path as in this test, EndpointsFilter -> doFilter is never called, this occurs because of this code snippet ServerFilterRouteBuilder.java. As a mental model, let’s think about the following: Let's assume we have an application configured with Prometheus and the following properties:
This causes calls to the prometheus point, even if they are defined as sensitive true, to still be displayed without security. This is due to the filter's behavior. Is there any filter that I can use that does not have this behavior of append the contextPath? |
…th should be concatenated
@sdelamo Since I couldn't get the filter to ignore the ContextPath in the filters, I added a new property to the ServerFilter to establish whether the ContextPath should be added or not. With this and adding the option to not put ContextPath in the security filter now the solution works and all tests pass. If you have any comments about the solution or need me to modify or test something, please let me know. |
Any news about this improvement? |
I'm still waiting for approval :) |
@graemerocher @sdelamo ping |
it is scheduled for 4.5 |
Merged with #10870 Thanks for the contribution |
#7552 The idea of this MR is to create the endpoints.all.context.path property that can be used to separate the management context-path from the server.context-path
With this change, the behavior of the paths is as follows:
config:
micronaut.server.context-path=/foo
endpoints.all.context-path=/fff
endpoints.all.path=/eee
Now:
Default app -> http://localhost:8080/foo
Management -> http://localhost:8080/fff/eee
Before
Default app -> http://localhost:8080/foo
Management -> http://localhost:8080/foo/eee
config:
micronaut.server.context-path=/foo
endpoints.all.path=/eee
Now:
Default app -> http://localhost:8080/foo
Management -> http://localhost:8080/foo/eee
Before
Default app -> http://localhost:8080/foo
Management -> http://localhost:8080/foo/eee
With the addition of this property there should be no change in behavior in relation to the current properties.