|
|
|
|
|
||
|
||
| 
XHR level 2ではクロスドメインXHRがサポートされる、で、FirefoxとかChromeとかSafariの最新版だと既に普通に使えるようになっている。
HTTPヘッダで Access-Control-Allow-Originを指定することで特定ドメインからの読み込みを許可することが出来る。*だと全部許可になる。
今までJSONPを使っていたAPIは、実質的に全てのドメインからアクセスを許可してる状態なので、HTTPヘッダに Access-Control-Allow-Origin: * を追加してやるといいんじゃないでしょうか。
JSONPはscriptタグを動的に生成してdocumentに追加するという方式なので、もしJSONP APIの提供元がevilなscriptを配信していた場合、呼び出し元はそれを検知することが出来ない。クロスドメインXHR + JSON.parse(evalしないようにする)の組み合わせなら、ドメインを乗っ取られたり経路で改竄されたりしても、scriptの混入の危険が無いので、安心してAPIを利用することが出来る。あとはDOMノード追加するコストよりXHRの方が速そうだし、JSONではないデータをやり取りしたりとか、そういうメリットもあるだろう。外部ドメインからJSONPなAPIを利用するライブラリを作る場合、ブラウザのバージョンが古いならクロスドメインのリクエスト投げる前にエラーになるだろうから、XHR level2を試行した後、JSONPでの取得を試みるとかの方が良いかなー、と思ってたりします。
この前Shibuya.jsの会合でamachangが「既にcrossdomain.xmlが普及してるから使えばいいんじゃないの」的なことを言ってて、それに対してセキュリティ上色々問題あるよという話をした。
仮にXHR level 2のクロスドメインアクセスポリシーがcrossdomain.xmlを使っていたらという話。
そんなわけなんでリクエスト前にポリシーファイルを取得するのは冗長だったり安全に実装するのが難しかったりするのでHTTPヘッダ使うのが楽なのだろうなーと思いました。許可されてるかどうか分からないうちにとりあえずリクエストを投げちゃうのが気持ち悪いといえば気持ち悪いけど、それはimgタグとかでも可能なので。
それよりIE8がわざわざ別のXDomainRequestを作った理由が良く分からない、クロスドメインサポートしてるか判別しやすくするため？それなりに意味があるのだと思うけど、独自実装はなるべく使いたくないですね。
s-aska2010/11/13 11:55hidden要素のvalue属性に値を入れて取り出すという方法だと安全という事はないでしょうか、いかがでしょうか。
mala2010/11/13 13:25js側で生の値が必要な場合はそうです。が、js側でエスケープ済みかどうかを意識する必要があります。画面出力したりevalしたりするのであれば安全ではないです。本文に追記しました。
