Frank you are absolutely correct about the description of how DWR works today. What I have done is exactly what you are thinking of: made DWR work through the normal WebWork chain. So, all incoming DWR requests are done to a single entry point that is than initializing/making the request pass through the WebWork normal chain. In this case there will be no security issue: you have the exact same options as for a normal request.
hth, ./alex -- .w( the_mindstorm )p. On 5/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> 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; http://www.opundo.com/shootfoot.htm > ./alex Frank --------------------------------------------------------------------- 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]
