-
Notifications
You must be signed in to change notification settings - Fork 81
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[WFLY-15452] - modify ajp-listener to allow specifying pattern for aj…
…p request attributes
- Loading branch information
Showing
1 changed file
with
120 additions
and
0 deletions.
There are no files selected for viewing
120 changes: 120 additions & 0 deletions
120
undertow/WFLY-15452_ajp-listener_allowed_attr_pattern.adoc
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,120 @@ | ||
= modify ajp-listener to allow specifying pattern for ajp request attributes | ||
:author: Modify ajp-listener to allow specifying AJP_ALLOWED_REQUEST_ATTRIBUTES_PATTERN | ||
:email: [email protected] | ||
:toc: left | ||
:icons: font | ||
:idprefix: | ||
:idseparator: - | ||
|
||
== Overview | ||
|
||
Since UNDERTOW-1667 one can set additional AJP request attribute parsing permission via env variable. However there is no way to set it in WFLY config/model. This RFE's goal is to make it possible. | ||
|
||
== Issue Metadata | ||
|
||
=== Issue | ||
|
||
* https://issues.redhat.com/browse/WFLY-15452[WFLY-15452] | ||
|
||
=== Related Issues | ||
|
||
* https://issues.redhat.com/browse/UNDERTOW-1667[UNDERTOW-1667] | ||
* https://issues.redhat.com/browse/UNDERTOW-1977[UNDERTOW-1977] | ||
* https://issues.redhat.com/browse/WFLY-15453[WFLY-15453] | ||
|
||
=== Dev Contacts | ||
|
||
* mailto:{email}[{author}] | ||
|
||
=== QE Contacts | ||
|
||
* mailto:[email protected][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 | ||
|
||
* 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 pattern via model/xml. | ||
|
||
=== Nice-to-Have Requirements | ||
|
||
=== Non-Requirements | ||
|
||
== Backwards Compatibility | ||
|
||
Possibly. Subsystem transformers should be able to handle it. | ||
|
||
=== Default Configuration | ||
[literal] | ||
<subsystem xmlns="urn:jboss:domain:undertow:12.0" default-server="some-server" default-servlet-container="myContainer" default-virtual-host="default-virtual-host" instance-id="some-id" statistics-enabled="true"> | ||
... | ||
<server default-host="other-host" name="some-server" servlet-container="myContainer"> | ||
... | ||
<ajp-listener ... allowed_request_attr_pattern="(?:apple|banana)" .../> | ||
... | ||
</server> | ||
... | ||
</subsystem> | ||
|
||
=== Importing Existing Configuration | ||
|
||
No steps should suffice, as it would mean defaulting to 'null', which is default value in undertow source. | ||
|
||
=== Deployments | ||
|
||
Not affected. | ||
|
||
=== Interoperability | ||
|
||
Not affected. | ||
|
||
== Implementation Plan | ||
|
||
Done. | ||
|
||
== Security Considerations | ||
|
||
Possibly. UNDERTOW-1667 is a CVE, so this RFE should be documented well, in order to warn users of potential exposure. | ||
|
||
== Test Plan | ||
|
||
Unit tests should cover new functionality(there is already test case covering AjpListener). | ||
|
||
== Community Documentation | ||
|
||
Task for WFLY documentation already exist - WFLY-15453. HOwever, this is model change and there is model reference doc generated, so its unclear which approach is better? | ||
|
||
== Release Note Content | ||
//// | ||
Draft verbiage for up to a few sentences on the feature for inclusion in the | ||
Release Note blog article for the release that first includes this feature. | ||
Example article: http://wildfly.org/news/2018/08/30/WildFly14-Final-Released/. | ||
This content will be edited, so there is no need to make it perfect or discuss | ||
what release it appears in. "See Overview" is acceptable if the overview is | ||
suitable. For simple features best covered as an item in a bullet-point list | ||
of features containing a few words on each, use "Bullet point: <The few words>" | ||
//// |