On Sun, 24 Jun 2001, Martin Cooper wrote:
> This seems to me to be a "necessary but not sufficient" check. That is, to
> ascertain that a valid user is logged on, it may be necessary to check for
> the existence of a particular session attribute, but it is unlikely that
> such a test, by itself, will be sufficient to make the determination.
>
> Here's a somewhat more elaborate suggestion for how logon/session validation
> might be handled.
>
> 1) In struts-config.xml, allow an optional entity <session-check>, which has
> two optional (and mutually exclusive) attributes, 'attribute' and 'type',
> and which allows <forward> entities within it.
>
> 2) If the 'attribute' attribute is set, Struts will check for the existence
> of an attribute with this name in the session. If it is not present, and a
> <forward> named "default" exists, Struts will forward (or redirect)
> according to that forward.
>
> 3) If the 'type' attribute is set, Struts will first instantiate an object
> of the class specified by that attribute, and then call the sessionCheck()
> method on that object. This method returns the ActionForward object for
> where to go next, or null if everything is OK.
>
> Does this make sense?
>
> --
> Martin Cooper
>
A couple of thoughts on the subject:
* For the 'attribute' attribute, a <forward> named "default" would
have to be a global <forward>, right?
* For the 'type' attribute, should the object implement a specific
interface, or extend a particular base class? Let's say we call
it ActionSessionCheck. Doing this would let us instantiate an
ActionSessionCheck instance at application startup and reuse it --
plus it can be configured with references to the owning ActionServlet
so that it has access to all the other resources.
* If we have ActionSessionCheck, then the functionality of the "attribute"
attribute can be implemented in a default ActionSessionCheck, without
needing to be a special case. Combining all this together with the
ability to configure such an instance with <set-property> subelements
(we are using Digester, after all :-), you could simplify configuration
to something like this:
<session-check type="org.apache.struts.action.AttributeSessionCheck">
<set-property property="attribute" value="user">
<set-property property="forward" value="logon">
</session-check>
to configure a class that checks for the 'user' attribute in the
current session, and forwards to the ActionForward named 'logon' if
not found. Does that make sense?
* We should probably offer a custom tag implementation of the same
conceptual functionality (a la <app:checkLogin> in the example app)
for people to protect pages that might get accessed directly by users.
* In the past, when faced with the need to add configuration for
"simple" things (i.e. binary decisions, or simple one-property
values), Struts currently uses initialization parameters for the
controller servlet. Looking to the future, it probably makes more
sense to add a <configuration> element near the beginning of the
DTD's list of allowed elements (so that settings here can affect
later evaluations) for controller configuration things (including
the <session-check> being proposed here. As a migration aid, we
could accept settings from either place for the existing parameters,
including: application, bufferSize, content, debug, detail,
factory, formBean, forward, locale, mapping, maxFileSize,
multipartClass, nocache, null, tempDir, validating. (We'll need
to keep the "config" initialization parameter to point at the
correct struts-config.xml resource itself. Does that make sense?
Craig
