Search Type: Posts; User: naapuri
Search: Search took 0.01 seconds.
18 Nov 2009 2:52 AM
How I think that the example is broken: if I try to input the string "<b>foo" in a text field, it is displayed as a bold "foo", not as "<b>foo".
16 Nov 2009 11:34 PM
Foggy, please re-read my previous post with the <blink> tag example. Let's talk about text/plain content now.
The user writes text/plain content and expects to get that back *verbatim*. Let's call...
16 Nov 2009 10:27 PM
I'd like to hear how you would fix 'the <b>foo problem' I mentioned earlier.
If we have user-supplied text/plain data, "<b>foo" is a perfectly valid string. One could write an article...
16 Nov 2009 1:07 PM
as you probably noticed, the problem still exists, even though the thread is old.
Even 'the <b>foo problem' I mentioned earlier (not the actual XSS problem, but a sign of the larger...
27 Nov 2008 4:32 AM
I wanted to create a drag'n'drop tree, similar to this: http://extjs.com/deploy/dev/examples/tree/reorder.html - but with something fancier than plain text as the node text. But it seemed...
22 Sep 2008 11:35 AM
fallenrayne, I'm *not* suggesting that data should be encoded on the client before writing it the database.
I'm into a model where data is transferred in JSON or XML packets both directions,...
19 Sep 2008 8:11 AM
Thanks for the reply again.
My concern was about a scenario of using the grid component: YES, the '<b>foo' stored in the database would be encoded to '<b>foo' on the server and then rendered...
18 Sep 2008 3:22 PM
Ok, I think we are getting to the point. I'm using a client-side encoding for reasons you mention. I just set up the encodeHtml renderer in my editable grid, and everything is fine.
10 Sep 2008 1:41 AM
I'm not suggesting to implement WRITE-safety on the client.
See the two options in my previous mail. In option 1, this implies that the server must first decode and then re-encode the data sent by...
9 Sep 2008 5:37 AM
I've been talking about two scenarios and I think that you are now commenting on something else than these two things.
First, there are possible XSS problems, if a developer forgets to use...
9 Sep 2008 5:06 AM
jgarcia, I agree that it's very good to be able to write any html to buttons and such. :) I only meant to criticize the method/property *names* that are misleading.
However, I think that in 99% of...
9 Sep 2008 4:47 AM
Would you care to elaborate on this one?
Are you saying that a framework that defaults to encoding html entities would make people write worse code? I think that's a bit like saying that seat...
9 Sep 2008 4:39 AM
jgarcia, thanks for commenting again. I think we can agree that security should be all parties' responsibility. A framework can only do so much for the security, but I think that the approach taken...
9 Sep 2008 2:18 AM
Foggy, this particular Grid problem ("foo<b>") I described is not an XSS problem, as I said. But this example shows how the present Ext Grid forces the developer to *manually* take care of HTML...
9 Sep 2008 12:47 AM
ApocalypseCow, thanks for your reply. I think it's all about data types. If we are talking about plain-text data, it's not "unsafe" until it's rendered as raw HTML. And the same data source could be...
8 Sep 2008 11:38 PM
This seems to be a fundamental decision by the Ext team to ignore the XSS problem by forcing the user to remember to type all these encodeHtml calls *everywhere*. And this isn't only about the Grid...
Results 1 to 16 of 16