> But beside the point, we can't count on every user to be wise. We have > to have a way to protect them from themselves. I've just verified on > my own system there are some definite vulnerabilities with the utf > pages. Hans has point out others offlist. Unfortunately, these both > occur even with utf pages turned off. So this is something we need to > be careful about, on our end, and not put that responsibility on the > user end.
Just a quick comment about utf-8: utfpages: false does not mean utf is turned off. With charset=utf-8 in the skin's HTML head all wiki pages will be treated as utf-8 encoded. And forms allow utf-8 encoded character input, unless it is explicitly filtered out. Generally for content we want to allow this. For page names we want percent encoding and forbid some characters. For info (in-text) variables we probably want to allow, again with disallowing certain characters. For other variables we could be more strict and insist on alphanumeric characters, plus a few others. And unless input is urldecoded or otherwise filtered/restricted the php functions deal with utf-8 encoded characters, not percent encoded strings. To help not get confused in my testing I use echo statements to see the vars at various points in the process, and use testpages and test input with Linly's nice Chinese characters, which show up in the echo, soi know; aha, unrestricted utf-8 here! Cheers, Hans --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
