[jira] [Closed] (WW-2635) Flash scope

["Lukasz Lenart (Jira)" <ji...@apache.org>]

     [ 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)