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]
