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

Validate monitoring header overrides at parse time #47848

Merged
merged 4 commits into from
Nov 4, 2019
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -209,7 +209,23 @@ public Iterator<Setting<?>> settings() {
*/
public static final Setting.AffixSetting<Settings> HEADERS_SETTING =
Setting.affixKeySetting("xpack.monitoring.exporters.","headers",
(key) -> Setting.groupSetting(key + ".", Property.Dynamic, Property.NodeScope));
(key) -> Setting.groupSetting(
key + ".",
settings -> {
final Set<String> names = settings.names();
for (String name : names) {
final String fullSetting = key + "." + name;
if (HttpExporter.BLACKLISTED_HEADERS.stream().anyMatch(name::equalsIgnoreCase)) {
Copy link
Member

Choose a reason for hiding this comment

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

Why use equalsIgnoreCase? I don't see where we've been case insensitive in setting names before, and I'm not sure we should change behavior here while trying to add validation.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

HTTP headers are supposed to be case insensitive, so without the case insensitive check, a user could supply an override for "content-length" even though "Content-Length" is on the header override blacklist. If that's not a concern here or this is the wrong place to check that, I can make it a case sensitive check.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rjernst, would you prefer the HTTP header name check here remain case-sensitive?

Copy link
Member

Choose a reason for hiding this comment

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

I'm open to it being case-insensitive, but changing that behavior should be separate PR. This PR is just about adding validation to the parsing as it currently exists.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@rjernst, I've restored the original case-sensitive check here.

throw new SettingsException("header cannot be overwritten via [" + fullSetting + "]");
}
final List<String> values = settings.getAsList(name);
if (values.isEmpty()) {
throw new SettingsException("headers must have values, missing for setting [" + fullSetting + "]");
}
}
},
Property.Dynamic,
Property.NodeScope));
/**
* Blacklist of headers that the user is not allowed to set.
* <p>
Expand Down Expand Up @@ -486,16 +502,7 @@ private static void configureHeaders(final RestClientBuilder builder, final Conf

// record and validate each header as best we can
for (final String name : names) {
if (BLACKLISTED_HEADERS.contains(name)) {
throw new SettingsException("header cannot be overwritten via [" + concreteSetting.getKey() + name + "]");
}

final List<String> values = headerSettings.getAsList(name);

if (values.isEmpty()) {
throw new SettingsException("headers must have values, missing for setting [" + concreteSetting.getKey() + name + "]");
}

// add each value as a separate header; they literally appear like:
//
// Warning: abc
Expand Down