CORSまとめ - Qiita
今更ですが、CORS (Cross-Origin Resource Sharing)を色々試していたら、思っていた以上に色々パターンがあることに気づいたので、改めてその扱い方についてまとめてみました。 そもそも 現在のWebブラウザでは、あるWebサイトが持つ情報が別の悪意あるWebサイトに悪用されるのを防ぐために、Same-Origin Policy(日本語では同一生成元ポリシー)が適用されます。 例えば、あるWebサイト https://guiltysite.com をブラウザで表示している時に、このWebページからXMLHttpRequest(以下、XHR)やFetch APIで別のWebサイト https://innocentsite.net からHTTP(S)でデータを読み込もうとすると、エラーになる、というわけです。 しかし、アクセス元が悪意あるWebサイトならともかく、データ
Web Pushのサーバ認証VAPIDを試してみる (旧題: GCMの登録が不要になったChromeのWeb Pushを試してみる)
※ 2018-2-26: VAPIDのRFC 8292対応ですが、FirefoxとMicrosoft Edgeが対応済みで、Chromeでも少々手を加えれば使えるようです。 W3CとIETFで標準化が進むWeb Pushですが、Firefoxでは事前の設定を特に必要としないのに対し、ChromeではAndroidアプリと同様にGoogle Cloud Messaging (GCM)の登録とキーやIDの取得が必要となります。従って、Webアプリ側では、Chrome専用のマニフェスト記述が、アプリケーションサーバ側ではGCMサーバの認証用に専用のHTTPヘッダの記述が必要となっています。 これに対し、ようやくプッシュサーバのアプリサーバに対する認証などの仕様について、IETFでの策定が進み、ChromeやFirefoxで実装が進んできています。今回はこの新しいサーバ認証の仕組みを使って、GCM
ChromeでW3C Push APIを使ってみた - Qiita
※ (2017/7/4: Chrome以外のブラウザとの相互運用性を考慮する場合は、Web Pushへの移行を推奨します。Web Pushについては[改訂版] Web Pushでブラウザにプッシュ通知を送ってみる[旧仕様対応版]にまとめています。(なお、AndroidやiOSへのFirebaseプッシュ通知と統合して運用する場合は、Firebase JavaScript SDKの利用を検討した方がよいかもしれません。)) ※ (2015/11/27: 関連してFetch APIの使い方を簡単ながら別記事に書いてみました。) もう既に、ググると参考記事がいくらでも出てくるような内容ではありますが、個人的にいろいろと上手く行かなかったりしたこともあるので、参考までにまとめてみました。 さて、Chrome 42 (Android版を含む(!))では、Service Workersとの組み合わせで
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
