I don't care much about this... I would say -0. I see that you use includes primarily for composition. I use included actions also as request targets, I need them to be accessed from browser, i.e. public, so your suggestion is of no use for me.
If you need this feature then who am I to oppose :-) But this feature can promote action chaining too, and chaining has always been considered as bad thing. On the security side, it does not bother me if a user submits to an included action directly instead of doing it through a designated HTML form. I think that an action should not blow up if it is called with bogus parameters. On 9/6/06, Paul Benedict <[EMAIL PROTECTED]> wrote:
For a lack of a better subject line. Let me explain. I have some actions which are not supposed to be accessed by users. They are mostly for internal uses within the program. Specifically, I like to include many actions on a page and build a poor-man's portlet. So what I have, architecturally speaking, is one action whose view triggers a whole bunch of other actions. My thoughts lead me to this: while it is very low probability that these included action paths can be guessed at, I nevertheless do not enjoy it being above zero. I propose adding a new attribute which dictates when an action may be invoked. I do not have a favorite choice among my ideas, but here they are: 1) A public attribute; defaults to true. 2) A private attribute; defaults to false. 3) A dispatcher attribute; defaults to all; allows request|include|forward|error (like the filter dispatcher attribute of web.xml) For my needs, I want to be able to say which action mappings may not be directly accessed; they must be forwarded to or included by. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
