Chris Nokleberg wrote:
On Thu, Jan 02, 2003 at 08:00:41PM +0100, Rickard Öberg wrote:
But one of the reasons to get rid of .action is that it exposes the
implementation. ".jsp" does the same thing!
Absolutely. But at least XWork would be hidden.
AFAICT there's no expressive difference between what I suggested and using the .action way, except that the former can only map a JSP to one action.Why not allow for arbitrary URLs, even when you want to use JSP as your view technology? Then it can just become another templating language. Intercepting calls to ".jsp" pages is not very Model 2. Maybe Model 1.5.
Can you explain how is it "not very Model 2"?
What does that have to do with having a JSP specific View class?Pretty much, yes. There's no real trouble with allowing .action invocations as before, but if it's possible to get them to go away it would be nice.*If* actions are always tied to a path (or paths), *and* there is a filter controller, then: a) Your URLs can be anything you want. b) You can use the same JSP as the view for multiple actions.
I think in the latest design there is a View factory chain whichI don't see any point in having a JSP View class as opposed to a generic "include a servlet" View class.
produces a View class, just like for actions. A ".jsp" view should
result in a JSP View class, which will just forward the request to a JSP
page via a RequestDispatcher.
The problem is that you have to then allow requests directly to .jsp files. What happens when you want to switch to velocity?
If you have been using .jsp and want to switch to Velocity without breaking URL's then map the Velocity-servlet to .jsp and use that extension for the templates.
Or, map JSP's to .html and use that for Velocity templates too in order to hide both completely.
But the security problem is not with pages really, but with actions. If the request is stopped at the View stage it's already too late: you may have executed code that the user was not allowed to execute.In servlet 2.3 (and by default in 2.4), a forward this way will *not* go through the filter chain again. This de-facto prevents against public requests to your jsp view pages--they can only be run by the controller.
Since a request to a ".jsp" will not be mapped to any action, no action
will be run.
With the servlet filter approach it would. We seem to be miscommunicating here, but I'm not sure where it gets wrong.
That is how I have implemented the filter currently: if there's an action for the JSP, then execute it, otherwise do nothing (i.e. run JSP as usual).There may be a wrinkle in that the filter controller would by default let any request flow through if there is no action mapping, which could still allow a request to a .jsp to find and execute a page, but fixing this is an implementation detail (maybe as simple as throwing an exception if the request matches "*.jsp").
/Rickard
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
