[
https://issues.apache.org/jira/browse/WW-2635?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukasz Lenart closed WW-2635.
-----------------------------
Resolution: Won't Do
Thanks for the proposal and the attached patch — it has held up remarkably well
as a design sketch. After review against the current (7.x) framework, we are
leaning toward closing this as *Won't Do*, for three reasons:
*1. The primary use case already ships.* The headline scenario in this ticket —
action messages / errors surviving a redirect (POST-Redirect-GET) — is covered
by the {{store}} interceptor ({{MessageStoreInterceptor}}). It stores
{{ValidationAware}} messages, errors, and field errors in the session across a
{{ServletRedirectResult}} and clears them on retrieval, in {{STORE}} /
{{RETRIEVE}} / {{AUTOMATIC}} modes. That is flash scope for the case that
motivated most of the demand here.
*2. The remaining delta conflicts with the modern security model.* What this
ticket adds beyond {{store}} is flashing _arbitrary typed action data_ across a
redirect by copying a session-held map back onto the target action. Since this
patch was written, Struts moved to an opt-in parameter model
({{@StrutsParameter}}, {{ParameterNameAware}}, excluded-parameter patterns,
allowlist OGNL member access) specifically because uncontrolled property
population is the root of most historical Struts CVEs. A {{FlashInterceptor}}
that re-populates an action from stored values would either have to route
through that same gating (at which point it is largely re-implementing
{{ParametersInterceptor}}) or bypass it — and bypassing it is a
parameter-injection surface, since session-stored values can ultimately
originate from earlier untrusted input.
*3. The safe form is a thin wrapper users can own.* The version that _does not_
touch the value stack — a typed, single-read session bucket with automatic
expiry — is a small amount of application-side code (put in session, read once,
remove) and does not warrant a framework-level result/interceptor pair with its
own security contract to maintain.
Given the 17-year age, low vote count, and the above, we do not think this
clears the bar for inclusion.
*Recommendations for anyone landing here:*
* For messages across a redirect: use the {{store}} interceptor.
* For a typed object across a redirect: place it in the session under a
request-scoped key and remove it on first read.
If someone has a concrete use case that neither of those covers, please add it
here and we will reconsider.
> Flash scope
> -----------
>
> Key: WW-2635
> URL: https://issues.apache.org/jira/browse/WW-2635
> Project: Struts 2
> Issue Type: New Feature
> Components: "New" API
> Reporter: Guillaume Bilodeau
> Priority: Major
> Fix For: 7.3.0
>
> Attachments: FlashInterceptor.java, FlashInterceptorTest.java,
> FlashResult.java, FlashResultTest.java
>
>
> I have developed a FlashResult / FlashInterceptor pair to implement "flash"
> scope in a way that follows the usual Struts2 principles and respects its
> "feel".
> It basically works like the ServletActionRedirectResult except that instead
> of converting all extra parameters to strings and adding them as HTTP
> parameters in the redirect URL, it creates a HashMap using these parameter
> key/value pairs with no conversion and stores it in the user session. On the
> next HTTP request the FlashInterceptor, if properly added to the interceptor
> stack, will retrieve this map and copy the map entries to the target action
> using the parameter keys. It should work for all data types.
> To function correctly this approach assumes that bug WW-2170 is fixed. The
> implementation also borrows a lot from the ServletActionRedirectResult and
> some refactoring should
> be done.
> While there may be issues with flash scope in general with regards to
> repeated GETs being inconsistent, there are some valid use cases such as when
> saving messages to be displayed after a redirect. I think it's good for the
> developer to have this tool and it could make a nice addition to the Struts2
> code base.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
