Skip to content

Instantly share code, notes, and snippets.

@davelnewton
Created March 4, 2015 13:56
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save davelnewton/177be8ef1ba42f0e8b9b to your computer and use it in GitHub Desktop.
Save davelnewton/177be8ef1ba42f0e8b9b to your computer and use it in GitHub Desktop.

[...] If there is another way of sending a variable from one Action to another Action directly, without using a form, I'm curious to know

As a URL parameter, e.g., http://foo.bar/somepath?id=nnn. Your concern regarding POST v GET is addressed below.

I also haven't mentioned using the session object because this variable will be precisely used as a key to obtain an object from the session Map.

What the value is used for is irrelevant. You're passing a variable into the view layer which immediately passes it back, via an additional request, to the same server that already knew the ID. Whether or not you keep it in the session doesn't matter--there's no reason you couldn't, though--it doesn't matter that a value in session is used to retrieve another value in session.

You'd need to remove it from the session again, unless it's some sort of "sticky" ID, e.g., you have a long-running conversation with the client around a specific domain object. An example would be you select a company, put that company's ID (or the whole company if practical) into the session, and all subsequent operations work on that company, until it's cleared from session, or set to a different company.

The URL parameter solution wasn't an option for me because I didn't want to expose the variable to users

Why not? Why does it matter?

With proper authorization in place the user can't access data they don't have access to anyway. If the "strictly monotonically increaasing" (SMI) nature of some DB's ID systems bothers you then only expose GUIDs, even if they're not the primary key.

A POST is only the barest step above showing an ID in the URL. "Security through obscurity isn't" means that security through obscurity isn't security at all, e.g., http://stackoverflow.com/q/3629134/438992. As noted there, there is some information that you may not want to expose if your IDs are SMI, hence GUIDs.

Using action properties in results is covered in the S2 documentation, e.g., https://struts.apache.org/docs/result-configuration.html and https://struts.apache.org/docs/parameters-in-configuration-results.html. (The site is down for me at the moment so the config snippets aren't showing up. IIRC these pages cover this topic, though. If I'm wrong, let me know, and I'll make some wiki edits.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment