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

[WFLY-14255] Make reuseXForwarded and rewriteHost configurable #444

Merged
merged 1 commit into from
Jul 3, 2024
Merged
Changes from all commits
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
@@ -0,0 +1,131 @@
= [Preview]Make ReuseXForwarded and RewriteHost configurable
:author: Bartosz Baranowski
:email: bbaranow@redhat.com
:toc: left
:icons: font
:idprefix:
:idseparator: -

== Overview

In some scenarios it is a requirement to reuse x forwarded or rewrite host header. Currently ProxyHandler flags controlling both are hardcoded to 'false', meaning mentioned functionality is not accessible.
This RFE adress this by introduction of model values that control mentioned flags.

== Issue Metadata

=== Issue

* https://issues.redhat.com/browse/WFLY-14255[WFLY-14255]

=== Related Issues

=== Stability Level
// Choose the planned stability level for the proposed functionality
* [ ] Experimental

* [X] Preview

* [ ] Community

* [ ] default

=== Dev Contacts

* mailto:{email}[{author}]

=== QE Contacts

* mailto:msvehla@redhat.com[Martin Svehla]

=== Testing By
// Put an x in the relevant field to indicate if testing will be done by Engineering or QE.
// Discuss with QE during the Kickoff state to decide this
* [ ] Engineering

* [x] QE

=== Affected Projects or Components

* Web/Undertow

=== Other Interested Projects

=== Relevant Installation Types
// Remove the x next to the relevant field if the feature in question is not relevant
// to that kind of WildFly installation
* [x] Traditional standalone server (unzipped or provisioned by Galleon)

* [x] Managed domain

* [x] OpenShift s2i

* [x] Bootable jar

== Requirements

=== Hard Requirements

* Being able to configure both flags via model:
- reuse-x-forwarded-header
- rewrite-host-header
baranowb marked this conversation as resolved.
Show resolved Hide resolved

[literal]
<subsystem xmlns="urn:jboss:domain:undertow:14.0" default-server="some-server" default-servlet-container="myContainer" default-virtual-host="default-virtual-host" instance-id="some-id" statistics-enabled="true">
....
<handlers>
<file case-sensitive="false" directory-listing="true" follow-symlink="true" name="welcome-content" path="${jboss.home.dir}" safe-symlink-paths="/path/to/folder /second/path"/>
<reverse-proxy ... reuse-x-forwarded-header="true" rewrite-host-header="false">
</reverse-proxy>
</handlers>
....
</subsystem>
Parameters will be present in reverse-proxy element(for standalone: /subsystem=undertow/configuration=handler/reverse-proxy=my-handler):
* reuse-x-forwarded-header
** Default: false
** Type: boolean
** Description: if true append(reuse existing) remote hop to x-forwarded-* headers, if not, previous value is discarded and remote hop becomes the value, otherwise set it to remote host.
* rewrite-host-header
** Default: false
** Type: boolean
** Description: if true set host header to connection remote end and create x-forwarded-host header.

=== Nice-to-Have Requirements

=== Non-Requirements

== Backwards Compatibility

Subsystem transformers should be able to handle it.
baranowb marked this conversation as resolved.
Show resolved Hide resolved

=== Default Configuration

No change.

=== Importing Existing Configuration

No steps, transformers should handle purging default value for previous configs.


=== Deployments

No. Default is still false for both, so there should be no change in behavior.

=== Interoperability

Not affected.

== Security Considerations

////
Identification if any security implications that may need to be considered with this feature
or a confirmation that there are no security implications to consider.
////

== Test Plan
baranowb marked this conversation as resolved.
Show resolved Hide resolved

== Community Documentation

Should be part of model reference. Possibly could be documented in Undertow as well?

== Release Note Content
baranowb marked this conversation as resolved.
Show resolved Hide resolved
See Overview

Choose a reason for hiding this comment

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

Hello @baranowb
Thanks for making the changes. Just a minor comment, the contents of this section is used to compile the release notes for WildFly. If that is done automatically through some scripts, then the release note for this feature might show "See Overview", so it would be good to update that.

Copy link
Contributor

Choose a reason for hiding this comment

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

It's not done via scripts and wouldn't be blindly copied into the announcement; it's just a convenience for me when I manually write the release announcement if the feature team has drafted suitable language instead of requiring me to start from scratch on a very busy day.

I don't want feature teams automatically blocking approving analyses based on this section, but it's helpful to me if the team comes up with suitable language that follows the basic pattern of how I introduce features in the release announcement blogs. At a high level vaguely understandable to user interested in what's new in WF, state what area was improved to allow you to do what that you couldn't before.

Note I'm not looking for adoc stuff here like the hyperlinks I always use, nor am I asking for boilerplate stuff like 'This feature is provided at the preview stability level.'