> First we need to really think about the best place to encode/decode
> the utf chars so that we have maximum, and simplest functionality.
> Switching the decoding to the final output of the markup table (as
> Hans suggested) will simplify a lot of code and make sure we never see
> a %encoded url anywhere (unless escaped--a whole other issue). And
> while probably don't want the underlying page content %encoded (for
> those who snoop around in there), there are some real possibilities if
> we did that could make UTF page names work anywhere in the system. For
> example, there's no reason we couldn't define some custom system var
> like {二} and get it to work. Or a function like [(二 ....)]. (We might
> already be able to do this with mapping). Crazy possibilities.
I think if we came to "{{p}::二}", that would be far enough. :)
> 1) Security. Though I haven't yet tested, I'm concerned someone could
> url_encode a XSS hack, drop it into any BoltWire comment box, and
> wreak havoc. It would bypass all filters (I have had to add %'s now to
> most filters to admit page names), and then if BoltWire blindly
> decoded everything, it could output perfectly formed javascript to the
> page. This may already be a vulnerability if you have the new utf
> pagenames enabled.
I know nothing about this, but why not just put a pair of <code></
code> surrounding the comment input, forcing all of the content become
pure text? No code allowed. Many blog script use this approach to
prevent xss or other things.
Cheers, linly
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---
