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

server: Warn in logs on admin mutations via GET. Mutations should be POSTed. #2971

Merged

Conversation

jmarantz
Copy link
Contributor

@jmarantz jmarantz commented Apr 3, 2018

Description:
When a mutating admin-console endpoint is reached, verify that it's a POST. For now, the operation succeeds but a warning log is printed.

This is a second attempt of #2912, which (a) contained an earlier version of the log-testing infra
from that was submitted #2930, and (b) was impacted by a merged commit that lacked a DCO.

This is a step toward fixing #2763

Risk Level: Low

Testing: //test/...

Docs Changes:

Link to Data Plane PR]
[in progress, will update]

Release Notes: [in progress, will update]

If this change is user impacting you must add a release note via a discrete PR to
version_history.rst.

API Changes: envoyproxy/data-plane-api#602

Deprecated:
Deprecates supporting admin mutations with a GET.

jmarantz added a commit to jmarantz/data-plane-api that referenced this pull request Apr 3, 2018
envoyproxy/envoy#2971 adds warning-checks that mutations should be POSTed.  This documents that status.  In a future PR, mutations will fail if they are not POSTs.

See envoyproxy/envoy#2763 for more detail.

Also adds a doc stub for @jsedgewick to fill in for /runtime_modify.
@ccaraman ccaraman assigned ccaraman and unassigned ccaraman Apr 3, 2018
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

nice. LGTM other than small nit.

@@ -758,7 +757,7 @@ void AdminImpl::createFilterChain(Http::FilterChainFactoryCallbacks& callbacks)
callbacks.addStreamDecoderFilter(Http::StreamDecoderFilterSharedPtr{new AdminFilter(*this)});
}

Http::Code AdminImpl::runCallback(absl::string_view path_and_query,
Http::Code AdminImpl::runCallback(absl::string_view path_and_query, AdminFilter* admin_filter,
Copy link
Member

Choose a reason for hiding this comment

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

nit: AdminFilter& admin_filter (can't be null)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

done

@@ -770,6 +769,14 @@ Http::Code AdminImpl::runCallback(absl::string_view path_and_query,

for (const UrlHandler& handler : handlers_) {
if (path_and_query.compare(0, query_index, handler.prefix_) == 0) {
if (handler.mutates_server_state_) {
const absl::string_view method =
admin_filter.requestHeaders().Method()->value().getStringView();
Copy link
Member

Choose a reason for hiding this comment

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

Sorry I just noticed this. Is there any reason to pass the entire filter here vs. just passing the request headers? Seems a bit cleaner unless it's necessary (we can avoid accessor, etc.).

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good question. What was on my mind here was eliminating the need for the dynamic_cast in https://github.com/envoyproxy/envoy/pull/2736/files/b9a4301d5b885ec2c244315791768edd68fa8352 in #2736 .

It makes sense to me to have admin handlers get more request context in general. And in the case of that PR, what's needed is Http::StreamDecoderFilterCallbacks* callbacks_. I'm also fine reducing the exposure now to just request-headers, and that could be broadened to the entire AdminFilter& in the future if needed. I admit, though, I don't really know whether those callbacks_ are truly needed to solve the hystrix issues.

It's a question of speculative generality vs. reducing the need for an antipated refactor in the future, and I'm fine either way.

Copy link
Member

Choose a reason for hiding this comment

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

My preference is to keep it simple for now unless there is a proven need, but I don't feel that strongly about it.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

ok done.

…ative generality.

We can always capture the AdminFilter* in a later PR if & when that is needed.

Signed-off-by: Joshua Marantz <[email protected]>
htuch pushed a commit to envoyproxy/data-plane-api that referenced this pull request Apr 4, 2018
envoyproxy/envoy#2971 adds warning-checks that mutations should be POSTed. This documents that status. In a future PR, mutations will fail if they are not POSTs.

See envoyproxy/envoy#2763 for more detail.

Signed-off-by: Joshua Marantz <[email protected]>
Copy link
Member

@mattklein123 mattklein123 left a comment

Choose a reason for hiding this comment

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

LGTM, just small nit.

@@ -31,6 +31,8 @@
namespace Envoy {
namespace Server {

class AdminFilter;
Copy link
Member

Choose a reason for hiding this comment

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

nit: not needed

@mattklein123 mattklein123 merged commit 26c5949 into envoyproxy:master Apr 4, 2018
Elite1015 pushed a commit to Elite1015/data-plane-api that referenced this pull request Feb 23, 2025
envoyproxy/envoy#2971 adds warning-checks that mutations should be POSTed. This documents that status. In a future PR, mutations will fail if they are not POSTs.

See envoyproxy/envoy#2763 for more detail.

Signed-off-by: Joshua Marantz <[email protected]>
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.

3 participants