どこでもスター

There was a problem posting your writeback.(007) っていわれてコメントが入らなかったので。
Big Sky :: どこでもスターグリースモンキーは開発者を殺す?

クリックしたところにどこでもスターをつけるためのセレクタを生成して自動でsiteinfoに書き込んでくれるグリースモンキースクリプト、みたいなかんじで介入していけますよ!

CSSセレクタの方が分かる人が多いからCSSセレクタにしたのはたしかに正しい選択なのかも。XPathを書ける人はあんましいない。ただ、ここの要素っていうのをXPathですら表現し難い場合がおおいのでCSSセレクタだと"どこでも"といえるほどどこでもにはつけられないのでは。

あれこれjsonにコード書かれたりしても大丈夫なようにどこで担保してるんだろう。
wikiに書かれたコードをサーバでパース(siteconfig.jsonにリクエストがきたタイミングでパースしてるっぽい)して、書いてある文字列全部をダブルクオートしてる。けど、なんか動作が怪しい。fo'o: var みたいに書くとjsonのほうが internal server error になる。
サーバでwikiをパースして安全なjsonにしてスクリプトでそれをまるまるevalしちゃうよりは、サーバはwikiに入ってるものをそのまま出して、クライアントでパースする方が危険な部分が少ないのでは。
悪意がなくても、jsonをサーバが補正できない形で書き間違ってるとsiteconfig全体がevalでfailするようになるのもよくない。危ない感じがするのでいろいろつついてみたいけどjsonが壊れてふつうに他のひとに迷惑がかかるのでやめた。


ただでさえGMのコンテキストだからクロスドメインXMLHttpRequestできてキケンなところで、だれでも書けるwikiのコードを評価するのだからそれをパースしているとはいえevalするのは避けた方がいいと思う。クライアントで安全にパースすることだってできるんだし。
それだとパースできなかったやつは無視するだけですむ。パースできないときにjson丸ごと評価に失敗、だと自分が書いたやつが悪くてうごかなくなってたみたいなのがあったりしそうですこしこわい。

加筆

JSONPGM以外から使えるようにする、のはきづいていませんでした。
考え直したら、いまのフィルタリングの実装がちょっと不安なだけでした。

いまの実装は書かれているJSONPを文字列として扱って特定のならびをエスケープする、という処理をしている印象を受けた。それだと出てきたJSONPJSONPとして有効なコードになっているかもわからないし、安全になっているか(文字列以外のものが入っていないか)もチェックしにくい。JSONPパーサを通して、それを改めてJSONPとして出力する実装が安心できやすいと思う。