Action Chaining, Sessions & Scopes

The chain result type, registered in struts-default.xml as org.apache.struts2.result.ActionChainResult, "invokes an entire other action, complete with its own interceptor stack and result". The target is a full action invocation: it runs its interceptors, its method and its result, and the response is whatever the target’s result writes. The result of the first action is never rendered. The parameters of the result are:

Source: Core Developer Guide — Chain Result, Parameters

The simplest chain uses the default parameter. add-chain runs AddBookAction and, when it returns success, chains to confirm; the second action uses the default stack, which contains the chain interceptor (see the next section).

Source: Core Developer Guide — Chain Result, Examples

Source: Core Developer Guide — Action Chaining, Chain Result

The output shows what chaining does. title and author were set by the params interceptor on AddBookAction and copied by the chain interceptor onto ConfirmAction; newId was computed by AddBookAction.execute() and copied too. The line shelves comes from a property that only AddBookAction has: the view found it because the first action stays on the value stack below the second one. And messages shows only Confirm ran: the message Added Dune that the first action added is not copied, because the interceptor does not copy messages, errors or field errors by default.

The browser’s URL is still /add-chain; there was one request and one response. That is the first of the problems of chaining: a reload repeats the first action (for a form that creates a record, a duplicate), and the address bar names an action whose result the user never sees.

The namespace parameter reaches an action in another package. With the admin package in the namespace /admin, which has its own confirm action, the first action can chain across namespaces:

Source: Core Developer Guide — Chain Result, Examples

The run of add-chain-ns?title=Dune&author=Herbert printed the same title, author and newId as the first chain, so the namespace parameter, like the target’s stack, behaves the same way as in the same namespace. See the Packages and namespaces page for how a namespace is chosen.

The method parameter invokes another method of the target. In Struts 7 the method must be allowed on the target, as for any action invocation (the allowed-methods element; the default is execute and the methods are checked at invocation, not only for the request URL). Without it the chain ends in an error page:

Source: Core Developer Guide — Chain Result, Parameters

With the allowed-methods element the run answered messages=[audit() ran] (the method audit of MethodAction ran, execute did not). Without the element the same configuration answered HTTP 404 with the message Method audit for action method is not allowed!. See the Wildcard mappings and method invocation page for allowed-methods.

The chain result keeps a history of the actions invoked in the current chain (the key CHAIN_HISTORY of the action context, a list of namespace/action!method strings). Before it invokes the target it checks whether the same namespace, action and method is already in the history; if it is, it throws a StrutsException "Infinite recursion detected" with the history. Two actions that chain to each other end like that:

Source: Struts 7.4.0 source — ActionChainResult

A request for loop-a answered HTTP 500 with the message Infinite recursion detected and the history starting //loop-a!execute. The parameter skipActions is the escape hatch, and its documentation is easy to misread: the Core Developer Guide calls it the list of "actions that could be chained to", but in the 7.4.0 source it is only a list of action names that the recursion check does not apply to (the check compares the action name only, not the namespace). A bounded loop, an action that chains to itself a fixed number of times, needs it:

Source: Core Developer Guide — Chain Result, Parameters

Source: Core Developer Guide — Chain Result, Parameters

With skipActions the request to count printed title=round 3 (three rounds in one request); the same mapping without the parameter, mapped as count-bad, answered HTTP 500 with Infinite recursion detected: [//count-bad!execute, //count-bad, not in `struts.xml.

The chain interceptor does nothing unless an action is already below the current one on the value stack and the result of the current invocation is a chain result (or no result yet): in the 7.4.0 source it copies only when the stack holds more than one object. A request that goes straight to confirm, with no first action, is therefore unaffected, and the interceptor is safe in every stack, which is why defaultStack and paramsPrepareParamsStack contain it. The stack basicStack, and any stack the mapping builds without chain, does not copy:

Source: Core Developer Guide — Chaining Interceptor, Examples

The run printed title=, author= and newId= empty, and shelves=[Fiction, Science] present: the chain happened (the first action is still on the stack and the view can read shelves from it), but no property was copied, so The own title of ConfirmAction stayed null and OGNL found that null on the top of the stack before it looked below. The distinction between "the first action is on the stack" and "its properties were copied" is the one that explains most surprises with chaining.

The copying goes through the setters of the target and the getters of the source. A property that has a getter on the source and a setter on the target with a compatible name is copied; everything else is skipped silently. Three collections of a ValidationAware action are excluded by default and three constants switch them on:

Source: Core Developer Guide — Chaining Interceptor, Description

The Core Developer Guide names the constants struts.xwork.chaining.copyErrors, struts.xwork.chaining.copyFieldErrors and struts.xwork.chaining.copyMessages. In 7.4.0 the names are the ones above, struts.chaining.* (the StrutsConstants class has struts.chaining.copyErrors, struts.chaining.copyFieldErrors and struts.chaining.copyMessages). The old names are not an error: a WAR with <constant name="struts.xwork.chaining.copyMessages" value="true"/> started and ran, and add-chain still printed messages=[Confirm ran], so the setting was silently ignored. A WAR with <constant name="struts.chaining.copyMessages" value="true"/> printed messages=[Added Dune, Confirm ran].

The interceptor’s parameters includes and excludes limit the properties that are copied; the page warns that giving both has undefined results. The stack that carries them is chainStack, whose reference name is chain (so the parameter prefix is chain.). To copy only the title:

Source: Core Developer Guide — Chaining Interceptor, Examples

The run printed title=Dune and empty author and newId. The opposite, chain.excludes set to author,newId, printed the same three lines, and one more line that deserves attention: messages=[Added Dune, Confirm ran]. The message copied although struts.chaining.copyMessages was not set. The reason is in the source: the default exclusion of actionErrors, actionMessages and fieldErrors is built only when the excludes parameter is null. An explicit excludes list replaces the built-in one, so a list that does not name the three properties lets messages and errors through. When excludes is used, add actionErrors, actionMessages and fieldErrors to it unless copying them is the intent.

An object that implements the marker interface org.apache.struts2.Unchainable is never used as a source. A source action that must not leak its properties declares it:

Source: Struts 7.4.0 Javadoc — Unchainable

Chained from add-unchainable?title=Dune&author=Herbert, the target printed empty title, author and newId; its messages were again only Confirm ran.

Chaining makes the data path into the target implicit: the target is populated from whatever happens to be on the value stack. Before Struts 7.2, a property of the first action that no request could set, because its setter had no @StrutsParameter, still reached the target through the chain interceptor, which ignored the annotation. Since 7.2.0 the annotation extends to chaining, but only if the constant struts.chaining.requireAnnotations is true; its default is false, so a default application keeps copying every property. The Bookshelf shows the risk with two actions:

Source: Core Developer Guide — Chaining Interceptor, Security Considerations

Source: Core Developer Guide — Chaining Interceptor, Security Considerations

A request straight to secret?approved=true&title=Dune printed approved=false and an empty title: the setters have no @StrutsParameter, so the params interceptor refused them. A request to approve-chain?title=Dune printed title=Dune and approved=true: the chain copied approved from the first action’s getter to the target’s setter, which a request could not reach. In an application where the target action trusts approved, that is a privilege path. The guide’s advice, which the example confirms, is to carry no authorization, trust, identity or approval state across a chain: re-derive it from the session or the security context inside the target.

Two defences exist, and they combine. The constant struts.chaining.requireAnnotations set to true (a global constant, there is no per-interceptor override) makes the interceptor copy only the target setters that carry @StrutsParameter:

Source: Core Developer Guide — Chaining Interceptor, Parameter Authorization

With the constant, approve-chain?title=Dune printed an empty title and approved=false (nothing was copied, because SecretAction has unannotated setters), add-chain printed no title, author or newId either (ConfirmAction is not annotated), and a chain to an annotated target worked: add-chain-annotated?title=Dune&author=Herbert to the action show-book (which has @StrutsParameter on its setters) printed title=Dune and author=Herbert. The interceptor is fail-closed: if the target class cannot be introspected, nothing is copied. The rejected properties are logged at WARN. The second defence is Unchainable on classes that must never be a source, and includes/excludes to copy only what the target needs.

The remark of the printed newId=B-4 in the annotated run is not a leak: the target has no newId, so the view read it from the first action that is still on the value stack. Chaining always leaves the whole chain visible to the view, whatever the interceptor copies.

The way to receive the map is the interface org.apache.struts2.action.SessionAware, which has one method, withSession(Map<String, Object>). The servletConfig interceptor of the default stack calls it before the action runs. Its siblings do the same for the other scopes: ApplicationAware (withApplication), ServletRequestAware (withServletRequest) and ServletResponseAware. The Core Developer Guide recommends these interfaces over ActionContext.getContext().getSession(), which it calls a bad practice.

Source: Core Developer Guide — Accessing Application, Session, Request Objects, Accessing from Java

The Bookshelf’s reading cart is a list in the session. The action, a normal SessionAware class with the four methods the URL pattern cart-* selects:

Source: Getting Started — HTTP Session, Using the HTTP Session Object In The Action Class

Source: Getting Started — HTTP Session, Using the HTTP Session Object In The Action Class

The view reads the session through the OGNL root name #session: <s:property value="#session.cart"/> in cart.jsp. A run with one cookie jar:

Source: Getting Started — HTTP Session, Accessing HTTP Session Objects In The View

The tutorial page uses an older signature, public void setSession(Map<String, Object> session), in its HelloWorldAction and describes an interceptor that injects the session "by calling the setSession method". In 7.4.0 the interface has withSession; a class that still has a setSession method but does not implement the new interface receives nothing. The Aware interfaces and the 6.0 rename are covered on the Actions page.

The SessionMap does not create an HttpSession when it is built. The servlet session is created on the first put (and by anything that calls request.getSession()). The Bookshelf shows the two sides. The action no-session (an action that only reads, rendering a session="false" JSP) answered without a Set-Cookie header; scopes, which calls session.merge("visits", 1, ...), answered with Set-Cookie: JSESSIONID=...; Path=/g9chain; HttpOnly. A JSP without session="false" creates a session of its own on the first request, which is the reason the Bookshelf views switch it off: a page that is only a view must not create a session per visitor (for crawlers, a very large number of them).

Source: Struts 7.4.0 Javadoc — SessionMap

The same property decides what happens in the view’s #attr. The Core Developer Guide says that the #attr stack value searches the page, request, session and application scopes in that order. In the Bookshelf a JSP with <%@ page session="false" %> printed attr.visits= (empty) for a value that #session.visits printed as 2, while #attr.servedBy (a request attribute) and #attr.opened (an application attribute) were found; the same view with the default session="true" printed attr.visits=3. The guide does not mention that a JSP that opted out of the session cannot see session attributes through #attr. Use #session.name when the scope matters, which it nearly always does.

Source: Core Developer Guide — Accessing Application, Session, Request Objects, Accessing from the View

The session is shared by every request of one browser: a page that loads three Ajax calls at once runs three actions with three action instances and one session map. The action instance is per request, the session is not, so the usual servlet advice applies to anything stored in the session: store immutable values or thread-safe collections, replace values instead of mutating them in place, and make session objects Serializable so that a server that persists or replicates sessions can handle them. The cart list above is mutated in place; two simultaneous cart-add requests can interleave, and a production cart would use a thread-safe list or a service. The scope interceptor of the next section adds a lock around the session, and no other built-in interceptor does.

The idle timeout of the session is not a Struts setting; it is session-config in web.xml (the Servlet fundamentals page covers it), with a default of 30 minutes on Tomcat. SessionMap.invalidate() ends the session, and the next put starts a new one with a new identifier. That is the answer to session fixation: when a reader logs in, the identifier the browser sent before the login must not remain valid after it. The LoginAction of the scratch app renews the session when it is asked to:

Source: Struts 7.4.0 Javadoc — SessionMap

Two requests to login?user=ann printed the same session id (303C73...), and login?user=ann&renew=true printed a different one (1577A5...); the user attribute survived because it was put after the invalidation. In a real application the renewal is done with request.changeSessionId() or by the container’s authentication (the Servlet fundamentals page), and the attribute holds a user id, never a password.

The Getting Started tutorial on the HTTP session ends with a security warning that is easy to skip. An action that implements SessionAware must not have a public getSession(): if the session map is reachable by name from a request, a request can write into it, because the params interceptor sets nested properties by their path. The tutorial tells the reader to do two things: omit the getter, and have the action implement ParameterNameAware (refusing names that contain session or request), or, for a whole package, set params.excludeParams on the default stack. The scratch app reproduces the dangerous shape with a getter that the annotation allows:

Source: Getting Started — HTTP Session, Best Practices When Using SessionAware

Against a browser that had logged in as ann, the request exposed?session.admin=true did nothing (the default parameter exclusion patterns of the params interceptor are the likely reason, since the same annotated getter under another name was open), but exposed?store.admin=true wrote admin=true into the real session: the next request to login printed admin=true. The defence by name covers only the exact words in the pattern; a getter that returns the map under another name is open. The rule is therefore two parts. Never expose the session map, or any other scope map, through a public getter, and keep @StrutsParameter away from anything whose type is a Map of session data. In 7.x the annotation is the second line of defence, because without it the request parameter does not reach the property at all; the example needed it to be reachable. The Interceptors page shows how the parameters interceptor’s exclusion patterns are replaced, not extended, when they are overridden.

Two small interceptors, in struts-default.xml but in no built-in stack, manage the session as a whole.

Source: Core Developer Guide — Create Session Interceptor

Source: Core Developer Guide — Clear Session Interceptor

Source: Core Developer Guide — Clear Session Interceptor, Examples

The first request to cart-session-created with no cookie answered Set-Cookie: JSESSIONID=...; Path=/g9chain; HttpOnly although the action wrote nothing to the session; after two cart-add requests, clear-session printed an empty cart, and the session identifier was unchanged (the cookie jar kept the same JSESSIONID, and no new Set-Cookie was sent). The guide’s page for cookieProvider repeats the sentence "This interceptor clears the HttpSession" by mistake (an inconsistency noted on the interceptors page); the sentence is correct only on the clearSession page.

Before the action runs, the interceptor sets the listed properties of the action from values stored in the session (or in the application map). After the action has run, and before the result is rendered, it reads the properties back from the value stack and stores them. It uses a pre-result listener for the second step, so the saved state is the state the view is about to show, including values changed by interceptors that run later in the stack. The session is locked around the action so that two requests of the same session do not interleave their reads and writes; the lock is for the session, not the application map, and the interceptor throws a StrutsException "Deadlock in session lock" if the lock is not obtained after about 30 seconds of waiting.

Source: Core Developer Guide — Scope Interceptor

Source: Core Developer Guide — Scope Interceptor, Parameters

The Bookshelf’s list page has a filter, an orderBy and a pageLen. The reader’s filter and orderBy should survive from one visit to the list to the next; the page length is a setting that, for the sake of the example, is shared by all users, so it goes to the application map.

Source: Core Developer Guide — Scope Interceptor, Examples

Source: Core Developer Guide — Scope Interceptor, Examples

The run, with one cookie jar, and the last request from a second browser that has no cookie:

Source: Core Developer Guide — Scope Interceptor, Examples

The second request, without parameters, got sci and author from the session. The third, from a browser with no session, got the action’s defaults all and title for the session-scoped properties, and 25 for pageLen: that was stored in the application scope by the first browser and is now the page length of everyone. Application scope has no per-user separation and no lock; a value there is global state, which is the reason for the guide’s note that application level consistency is not guaranteed. The keys in the session map are the key prefix and the property name glued together, with no separator: ...BrowseActionfilter.

The placement of scope relative to defaultStack changes the behaviour. The first mapping above puts scope before the default stack: the interceptor restores the stored values first, then the params interceptor of the default stack applies the request parameters on top, so a new request parameter wins and is saved at the end. The mapping browse-after puts it after:

Source: Core Developer Guide — Scope Interceptor, Examples

After one request with filter=sci&orderBy=author, a request with filter=newval printed filter=sci: the request parameter was applied, then the interceptor overwrote it with the stored value. The guide’s first example lists basicStack, hibernate and scope, in that order, which has the same effect for the parameters in basicStack; the guide does not say so. Put scope before the interceptor that fills the action from the request when the request should win, which is the usual case (the reader changes the filter), and after it only when stored values must be authoritative.

A request parameter named session.reset (the sessionReset parameter) skips the restore and saves the action’s current values, so the stored values return to the defaults. After browse-before?session.reset=1 the output was filter=all orderBy=title and the following plain request printed the same, so the reset stuck. The parameter type gives the same mechanism a start and an end, for the multi-step form of a wizard. The Bookshelf’s "add a book in three steps" stores title, author and shelf across three actions that share the key wizard:

Source: Core Developer Guide — Scope Interceptor, Parameters

Source: Core Developer Guide — Scope Interceptor, Parameters

Step 1 starts the wizard (the properties are saved but not restored), step 2 reads the earlier values and lets a request overwrite one of them, step 3 reads them and then removes the session keys (type="end"). The session map after step 3 holds only a nonce attribute that the default stack keeps there, and none of the scope interceptor’s keys; the wizard’s keys are gone. The last request shows the next surprising detail: running wizard-2 after the end re-created the keys with the value NULL. The interceptor never skips a null; it stores a placeholder object (NULLClass, whose toString is NULL) so that a session that gets serialized does not contain null references (the fix of WW-1803), and every action that lists a property saves it again after each execution. A session map printed in the view shows those placeholders; code that reads the keys of the scope interceptor directly would see them, which is another reason to read the properties from the action instead.

The default key is the class of the action, so two actions of different classes do not see each other’s values. The guide’s second example, with a literal key and a getter on the first action and a setter on the second, passes an arbitrary object between two actions. The Bookshelf version has ExportAction and BrowseAction, which both list filter under the key shelf:

Source: Core Developer Guide — Scope Interceptor, Examples

After export-key?filter=fantasy (which stored shelffilter=fantasy in the session), a request to browse-key printed filter=fantasy. With the default key, export-nokey stored the value under its own class key and browse-action-key (with key ACTION) used a third key struts.ScopeInterceptor:/:browse-action-key: none of them saw the others' filter. Without a key, as the guide says, the interceptor stores the values but does not set them on the other action.

Three details of the 7.4.0 behaviour were checked against the running scratch app.

Source: Core Developer Guide — Scoped Model Driven Interceptor

The interceptor works only with a ValidationAware action (every ActionSupport is) and, as the guide says, only if a session exists: "if no session exists, nothing will be stored", so the application is responsible for opening the session. The mode comes from the operationMode parameter:

Source: Core Developer Guide — Message Store Interceptor, Parameters

The parameters are operationMode, allowRequestParameterSwitch (default true) and requestParameterSwitch (default operationMode, the name of the request parameter that can set the mode). The guide says AUTOMATIC stores when the result is a ServletRedirectResult; the 7.4.0 pre-result listener tests for the interface Redirectable, which more result types implement (redirectAction is one).

The Bookshelf’s form action validates the title. When it fails it must send the reader back to the form with the error, and a success must send the reader to the form with "Saved". Both responses are redirects, so the messages go through the store:

Source: Core Developer Guide — Message Store Interceptor, Examples

Source: Core Developer Guide — Message Store Interceptor, Examples

Source: Core Developer Guide — Message Store Interceptor, Examples

The first submit, with an empty title, failed validation, returned input and redirected to store-form, which printed the stored field error. The next plain request to store-form printed no errors: retrieving removes the stored values, so they are shown once. The third request redirected after a successful save and printed Saved Dune.

Four details of this configuration matter, and one of them differs from the guide’s example.

Source: Struts 7.4.0 source — MessageStorePreResultListener

The message store stores the messages and errors, not the values of the form. A form that must be redisplayed with what the reader typed needs the value in the redirect URL, in the session through the scope interceptor, or a forward instead of a redirect. The validation framework and the input result are covered on the Validation page.