swdyh

Thak you for your report. I fixed this problem. Please try new version.

I added "Update Siteinfo" button to Options page. Please try to install latest version. Thank you.

I updated gisty version 0.2.4. Please try it. Thank you for your report.

これを入れるとWebページのスクリプトからもアクセス可能になると思います。 セキュリティの面から、これを可能にしていいのかどうかがわかりません。 少なくとも古いFirefoxだと危険がありそうで、現在のものだと大丈夫のような気もするんですが確証が持てません。 この点について、参考になるような情報があれば教えてください。

やっぱりセキュリティ関連の懸念があるのでこれはいれません。 目的はユーザスクリプト間のやりとりなので、Greasemonkey側にそういう仕組みを提案するのがいいと思います。

あともう一点、AutoPagerizeは独自のEventをいくつか出しています。 これらは、他のuserscriptでも受け取れるはずで、それらを利用すれば目的のことを達成できるかもしれません。

パッチありがとうございます。このパッチでこのエラーは解消されるので適用したいんですが、別の事情があるので保留させてください。 別の事情というのは、AutoPagerizeの要件としてクロスオリジンからデータを取得した合に処理を止める必要があるんですが、XHRだとリダイレクトを経由したときにそれを判別できないという問題があります。 この問題は根が深くてややこしいんですが、将来的には解決する可能性はあるのでそれを待ちながらしばらくはiframeを使う予定でいます。

アクセス先がAccess-Control-Allow-Originヘッダーでクロスオリジンのアクセスを許可している場合は、permissionと関係なくアクセスできるので、そういうケースを想定しています。 将来的に解決する可能性と書いたのは、documentTypeでdocumentを指定してresponse.URLを見る方法なんですが、実装に不備があるので採用していませんでした。 現状のChromeは、クロスオリジンへのリダイレクトはエラーになります。エラーになるのは都合が良いのですが、エラーになる理由がわかりません。CORSの仕様にリダイレクトでエラーにするということはなく、FirefoxやIEではエラーになりません。今後のアップデートでエラーが出なくなったとしても安全にできるということが必要だと思っています。 エラーがでなくなったとしてもresponse.URLをチェックしておけばいい、という手も考えられるんですが、現在のChromeは、セイムオリジンへリダイレクトしたときのresponse.URLはリダイレクト前のものを返していて、これと同じようになるとまずいです。クロスオリジンへのリダイレクトのエラーがなくなって、かつ、response.URLがリダイレクト後のURLを返すことが確認できたら、XHRを使って良いんじゃないかと考えています。 webRequestでやるのは考えたことがなかったです。こっちでいけるかもしれないですね、調べてみます。 リダイレクトとCORSとresponseTypeのdocument指定を組み合わせて実行するページを置きました。 http://autopagerize.net/cors.html

リダイレクトとresponse.URLがちゃんと機能していれば単純な話だったですけどね。 webRequestの方を調べてみたらブロックできそうでした。ありがとうございます。 permissionsにhttp://_/_やhttps://_/_を追加しないといけないのと、エラーがなくならないと実際にブロックが機能するかを試せないのが難点で、もう少し様子見しようと思います。

permissions足せばエラー消えますね。 content scriptでもbackgroundと同じようにpermissionが適用されたXHRが使えます。 webRequestでクロスオリジンアクセスをブロックするバージョンを作りました。 セキュリティに影響する変更なので、もう少し考えた上でマージするか決めようと思っています。 https://github.com/swdyh/autopagerize_for_chrome/compare/master...xhr_with_webRequest