On 5/24/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote:
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).
In the DWR-WW action invocation toy I have used when building
InfoQ.com, the action invocation passes through exactly the same
process as a normal request, so I have no concerns.
> 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).
That's in fact a good example of my arguement: good developers will
always know what to do to protect their site. Bad developers will not
know this. We are preparing a framework so that they are gonna use. If
they want to use it the wrong way, I would say that this is definitely
their problem. From my pov I just want that the simple things to be
extremely simple, and complex things possible. Other than this, it is
developers talent.
./alex
--
.w( the_mindstorm )p.
> cheers,
>
> ./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]
