Personally, I like these ideas. I think this design would lead people to cleaner solutions. I think it is time to make some decisions. I think Rickard should architect XWork. It would then be up to him to assign/delegate work on different modules, etc. I'm not convinced the current direction will lead to the best outcome. Rickard has established himself in past frameworks, application servers and his new portal product to earn the right to architect XWork. Besides, he mainly wrote WW. I may be wrong, but I don't remember an e-mail asking if he wanted to architect XWork or what role he wanted to play. I think this is a mistake. I think we should at least offer him the opportunity to architect XWork. I think his ideas have solidified and he is ready to right some code :). So, any dissenters? I'm not interested in getting XWork out the door quickly but when it does come out, I want it to be GREAT.
-Matt ----- Original Message ----- From: "Rickard Öberg" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, January 01, 2003 5:51 AM Subject: Re: [OS-webwork] Rethink > Jason Carreira wrote: > > Along this line, I've mentioned before that one of the top requirements > > I've got for a framework, and we're hopefully going to be switching to a > > new (better) framework in the next few months, is the ability to use > > J2EE declarative security to secure paths. This means that the way > > actions are invoked needs to be rethought. Currently, there's no way to > > keep people from executing your actions without creating a separate J2EE > > declarative security entry for each action (and each alias, etc). This > > is, IMHO, a HUGE drawback. > > I agree. There are a couple of things one can do here. First of all, > read-only actions should (IMHO) be invoked from WITHIN a page either > using an <action> tag (in JSP) or by using an include. That way the URL > doesn't reveal that WebWork is being used. The ServletDispatcher could > then be changed so that it only allows invocation through includes. This > alone would make a lot of security issues go away. > > Then the issue of read/write actions remain, which usually is of the > form "execute action, redirect to page depending on result". Here it > might be interesting to look at the new Portlet API which does something > like this: when a page is generated URL's are created and associated > with actions (see > http://www7b.boulder.ibm.com/wsdd/zones/portal/portlet/4.1api/org/apache/jet speed/portlet/PortletURI.html). > When the submit button of a form is clicked and the URL for the form has > been associated with an action that action is then invoked before > rendering the page. In this case it is thus the framework that triggers > the execution of the read/write action. It's not possible to execute > just by "knowing a URL". This in itself makes it easier to ensure that > code that "does things" is not executed out of context or insecurely. > > Since I'm personally ONLY going to be using WebWork/XWork through > portlets it'd be neat if XWork right from the start conformed to this > pattern. :-) Unfortunately the Portlet API draft has not been released > yet due to license issues (BIG ANNOYED *SIGH* GOES HERE), but hopefully > it'll be out soonish. > > And on the component note IMHO Portlets is the right level of > abstraction of components. I'd rather see XWork making it simple to do > portlets than trying to do our own packaging structure to do (basically) > the same thing. > > /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 > ------------------------------------------------------- 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
