On Wed, May 24, 2006 9:46 am, Alexandru Popescu wrote: > I am somehow a little confused by some of the comments... pls see inlined
What, me confusing?!?!? <sarcasm>NNNOOOOOOO...</sarcasm> ;) > On 5/23/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: >> On Tue, May 23, 2006 2:57 pm, Ian Roughley wrote: >> > Joe thought that a Struts2 >> > creator that read could read existing Struts2 configuration files, and >> > expose a package would be fairly simple to do. This would avoid >> > additional configurations. >> >> So by default all the Actions would be exposed as, in essence, service >> endpoints, in this package? I'm not sure I like that, sounds like a >> potential security nightmare. Or would you still have to enable what >> can >> be accessed? If you have to still write config to enable things anyway, >> I'm not sure how much it would save. I'd like to hear more about how >> Joe >> envisions this working. >> > > Not sure why it would be a security nightmare, because the actions are > already there, so somebody wanting to call them will however have > access to them. Now, it falls to the way you write your actions: are > they safe-written, than try and call me. > I am getting the feeling I am missing something :-(. Yes, Ian raised the same question... Here's what I was thinking... The way DWR works today, it instantiates and makes direct calls on some class, whether an Action or otherwise, it doesn't know or care. Note that this isn't an HTTP request, so it isn't going through any filters, interceptors, container-managed security, etc (and the class may or may not be part of a webapp to begin with of course). This is what I think might be (and I may be wrong) a security problem... Assuming we're talking about exposing Actionst... An Action isn't really just exposed in a typical webapp because an HTTP request has to go through whatever security you have set up. Many of us believe that externalized security is a best practice, so our Actions, indeed all our application code, doesn't have any security written into it, and we use some external security system (CMS, Netegrity, just some filter, whatever). Exposing Actions via DWR would open them up where they weren't open before because DWR would instantiate them and call methods on them, thereby bypassing any externalized security. A "normal" request to an Action doesn't bypass any of this. Even if you have security coded into the Actions, are you checking things on each method call? If not, I think it's still a (potential) security problem because DWR is going to allow direct method calls. Obviously my concern can be dismissed by insisting people code security into their Actions, but I don't think that's the best answer and would run contrary to what I see a lot of large corporations doing (certainly the one I work for is one example). > I am not sure how using Ajax can bring your server down. As you say, > Ajax calls are generally smaller, and I cannot see a way how you can > stop a bad developer to not take his tooltips from the server if he > really wants it. This is something that I think is called good > practice, and as we already know there will always be guys that are > not following it. Yes, the requests are generally (although not necessarily) smaller, but there can be a lot more of them. This is what I was referring to. If I have a UI that is making numerous small calls for tooltips (or something else that happens somewhat frequently, I don't want to be just picking on tooktips here!), and you have a decently high user load, that can be just as bad, and maybe even worse, than sending back a 50k HTML document rather than a 10k one that then requires those subsequent hits (i.e., the 50k document has the tooltips included and you use script to display them vs. a smaller initial document that then requires potentially numerous small requests subsequent to that initial load). Take Google Suggests as an example... they have some relatively complex code in place to throttle the number of requests it makes... think about how it works... if it was sending a request on each keystroke, and you get a fast typer like me, they would start to get a ton of requests, albeit small ones, and with enough users even their great hardware infrastructure would start to be affected at some level of scaling. They recognized this, and so they have code that actually slows down the request rate as the typing rate increases (or something to that effect, I'm not sure of all the details on how it works). > cheers, > > ./alex Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
