struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ian Roughley <>
Subject Re: JavaOne Ajax Discussion
Date Wed, 24 May 2006 16:38:14 GMT
There is a point that I would like to re-iterate.  The proposal is for 2 
separate approaches:

#1 - Have struts2 actions accept JSON / XML content when being called 
from a URI and have JSON/XML responses.  This is to allow struts2 to 
interact with any ajax/XHR framework, and would involve new interceptors 
and result types.

#2 - Use DWR for struts2 ajax-based widgets.  This should be a tight 
coupling of a UI element to a back-end function / action - i.e. get a 
list of things to display in the UI. 

The way I see #2 working is this - we have a specialized DWR object that 
accepts requests and calls an action (from a preconfigured package) the 
same way that it does today via Http. We also introduce several new 
interfaces - for example lets say AjaxList and AjaxObject.  The 
specialized DWR object has several methods that can be called depending 
on the type being returned (i.e. the interface that it uses to return 
the result, or whether the result is rendered and returned).

This is very similar to what Alex has.  Damn it!  You guys beat me to 
this ;-)


Frank W. Zammetti wrote:
> On Wed, May 24, 2006 11:10 am, Alexandru Popescu wrote:
>> Not sure how to read it, but call it request, or XMLHttpRequest it is
>> still a request hiting your server. Probably on the comet-part things
>> may be different, but that's completely another story.
> I think this is worth going at a little more because either I'm totally
> wrong, which is certainly possible, or there really *is* a potential
> problem... better to flesh it out now :)
> I know you know all this already, but just to level-set...
> As DWR works today, as I understand it... a request comes in to the DWR
> servlet... using the info from the dwr.xml file, it instantiates some
> class, be it an Action or not, and calls some method on it.  The result is
> then mashalled (not sure the form it takes, maybe JSON?) and is returned
> to the client, where it is unmarshalled into a Javascript object.  This
> all of course happens "under the covers" so that to the developer, the
> Javascript looks like it is executing on the client but is in fact making
> the call to the servlet and ultimately to the specified class.
> For example... in one app I did, I have this call:
> AddressBookManager.retrieveContacts(replyRetrieveContacts);
> The URL that gets called is:
> http://localhost:8080/instamail/dwr/exec/AddressBookManager.retrieveContacts.dwr
> The DWR servlet is of course mapped to /dwr/*
> Now, again, as DWR exists today, the call to the retrieveContacts() method
> of the AddressBookManager class is direct, i.e., AddressBookManager is
> instantiated by the DWR servlet and retrieveContacts() is called. 
> Therefore, if your webapp has security implemented outside the Actions,
> i.e., CMS or something, then it is effectively bypassed.  And even if you
> had security in the Action, it would have to be in every method, otherwise
> DWR could still bypass that security possibly, depending on how you
> implemented it.
> Now, one option would be to secure the calls to the DWR servlet.  You
> could set up a constraint to cover this particular call
> (/dwr/exec/AddressBookManager.* would probably do the trick), but then
> your writing a bunch of constraints to cover whatever calls you want
> constrainted.  And remember, a server serves by default, so anything you
> forget to constrain is wide open.  But, in the end, this would work I
> think.
> The other option is to have DWR not instantiate AddressBookManager and
> call retrieveAccounts() directly, but instead call an appropriate ACTION
> MAPPING for it via the usual HTTP.  This would incur all the security that
> you have implemented in your webapp, so there would be nothing new to add
> for DWR.  It would also in the case of WW go through the whole interceptor
> stack, which again is bypassed as DWR works today.  This is precisely what
> my suggestion on the DWR list a few months back was, but we were
> discussing Struts at the time, not WW.
> By the way, another tangential problem here is that in executing an Action
> in the manner DWR does today, i.e., not making an HTTP request, what's
> populated in ActionContext?  There isn't a session for instance, so what
> if the Action tries to pull something out of session?  What about the
> request parameters?  It seems obvious that calling an Action directly
> isn't the right answer.  Now, I'm not familiar with how DWR is integrated
> with WW today... maybe it already *does* make an HTTP request somehow.  It
> seems to me, as far as security goes as well as the issue of ActionContext
> and such, it has to.
>> About the other things I fully agree: a framework should never provide
>> something that  shoots the user in his foot... but a framework will
>> never be able to guarantee that if the user especially wants this to
>> happen it will not be able to do it :-).
> Hehe :)  Every time I hear or use the phrase "shoot yourself in the foot"
> with regard to programming, I can't help but think of the Real
> Programmer's list;
>> ./alex
> Frank
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message