はてなブックマーク

といった感じになるのですが、ブラウザはwebサーバのアドレスがわかっていてもWebRTCで相手(ピア)に送信する送信先(IPアドレスとポート)がわからないので、いきなりストリーミングの送受信はできない、ということに気づかないと先に進めない、というわけです。 シグナリングはテキストチャットの仕組みで 更に調べてみると、そのためのパラメータ(SDPやICE Candidateと呼ばれるもの)をやり取りするのにwebサーバが必要、ということを学ぶことになりました。この手順を、シグナリング、と呼ぶわけです。(詳細は@massie_gさんの記事「WebRTCの簡易シグナリング」あたりが参考になると思います。) ということは、SDPもテキストなので、SDPやICE Candidateの交換はテキストチャット同じ仕組みで対応できるということがわかったため、テキストチャットを応用すればWebRTCシグナリ

はじめに ChromeやFirefox、Opera、Edgeなどのブラウザでは、WebCrypto APIを使ってブラウザで鍵の生成や暗号化と復号、署名と検証ができるようになっていますが、今回はECDHを使った鍵共有(およびAES-GCMで暗号化)を題材として、WebCrypto APIの使い方の一例を試してみます。 ECDHでは鍵ペアの生成と鍵共有を行います ECDHを使って暗号化と復号を行うには、一般的には次のような手順となります(楕円曲線ディフィー・ヘルマン鍵共有)。 暗号化する側Aと、暗号化されたデータを復号する側Bの両方で、鍵ペア(秘密鍵・公開鍵)を生成 AとBが互いに相手の公開鍵を共有 Aは「Aの秘密鍵」と「Bの公開鍵」を使って共有鍵を生成し、この共有鍵でデータの暗号化を実行して、Bに送信 Bは「Bの秘密鍵」と「Aの公開鍵」を使って共有鍵を生成し、この共有鍵で暗号化されたデータ

はじめに ブラウザやプッシュ通知サービスによらず、標準化された手順でブラウザにプッシュ通知が可能になるWeb Pushに関連する技術仕様のRFC化が完了し、ブラウザとプッシュサービスへの実装もかなり整ってきています。そこで、Web Pushの使い方を改めて整理してみます。 なお、本記事は、Web Pushでブラウザにプッシュ通知を送ってみるのアップデートとなっています。 旧記事との差分 PushManager.supportedContentEncodingsがサポートされ、ブラウザが対応するContent-Encodingの種類を確認できるようになりました。Chrome 60以降、Microsoft Edge (EdgeHTML 17)が対応しています。 IETF仕様の変更により、aes128gcmというContent-Encodingが規定されました。Chrome 60以降、Firef

Media Source Extensionsを使ってみた (WebM編)では、Chrome(Blink)とFirefoxで「XHRやFetch APIで取得したWebMムービーをタグで再生する手段」としてMedia Source Extensions (MSE)の使い方を紹介しました。今回は、同様のやり方でMP4ムービーをXHRやFetch APIで取得して、MSEを利用してタグで再生するやり方を紹介します。 MSEによるMP4 (ISO Base Media File Format; 以下、BMFF)の再生をサポートしているブラウザとしては、Chrome 23以降、Safari 8以降 (OS Xのみ)、IE11 (Windows 8以降)、Edgeがあります。 その前に WebMでは、MatroskaフォーマットによるElement構造を採用しており、メディアストリームはCluste

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

※ 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

Google Cloud Messaging (GCM)(Chromeのみ)やWeb Push暗号化(Chrome, Firefox)でブラウザにプッシュ通知を送れるようになってきていますが、今回はそのデバッグ手段についてメモを書いてみます。 Service Workerのデバッグ 既に多くの記事で書かれており、詳しい説明が要らないような気がしますので、簡潔に。 Chrome chrome://serviceworker-internalsを開くと、インストール済みService Workerの状態を確認することができます。Service Worker自体はfetchやpushなどのイベント発生時にしか起動しませんが、このページから手動でService Workerを[Start]ボタンで起動して、[Inspect]ボタンをクリックすることで、開発者ツールを開いてService Worke

今更ですが、**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サイトならともかく

FirefoxがWeb Pushに対応したため、本記事の内容の多くは既に古くなっています。Web Pushの(主にサーバサイドでの)扱いについては、別記事「Web Pushでブラウザにプッシュ通知を送ってみる」にまとめていますので、そちらをご覧下さい。 いよいよデスクトップ版Firefoxでも44以降でService Workerとプッシュ通知が使えるようになります。Firefox 42, 43ではabout:configでdom.serviceWorkers.enabledとdom.push.enabledの両方をtrueにすることで有効化されまます。 基本的にはChromeのPush APIと使い方は同じですので、本記事ではChromeとの違いにフォーカスしします。 Firefoxのプッシュ通知 ChromeではGoogle Cloud Messaging (GCM)が使われますが、F

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

本記事のアップデートについて ※ Chrome 60以降、Firefox 55以降では、暗号化の手順に変更が生じます。詳細は、[改訂版] Web Pushでブラウザにプッシュ通知を送ってみるを参照してください。 2022-05-03: 今後メンテナンスを行わない見通しであることから、Javaで動作するデモの公開を終了いたします。長らくありがとうございました。なお、GitHubリポジトリはそのまま残しますので、古いコードでよろしければ参考になれば幸いです。 はじめに 先に「ChromeでW3C Push APIを使ってみた」や「Firefox (Developer Edition)でW3C Push APIを使ってみる」で書きましたように、ブラウザでのプッシュ通知の対応が徐々に形になってきています。 ChromeやFirefoxでプッシュ通知を通知だけではなくデータ(ペイロード)付きで送れる

Service Workersでプッシュ通知を受信できるようになったわけですが([1]: GCM)([2]: Web Push)、Chromeではバージョン48まではGCMで通知だけができるようになっただけで、メッセージ本体は通知を受けてからService Workerでサーバから改めて受け取るような実装をする必要があったりします。 ここで、Service Workersでは、XMLHttpRequestが使えません。その代わり、XMLHttpRequest (以下、XHR)に代わるWHATWGの仕様としてFetch APIがあり、Service WorkersではこのFetch APIを使うことになっていますので、その使い方を簡単に紹介します。 Fetch API自体は、Service Workers専用のものではなく、メインスレッドでもXHRの代わりに使うことが可能です。現時点で実装し

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Push API sample</title> <link rel="manifest" href="manifest.json"> </head> <body> <button id="register">インストール</button> <button id="push" disabled>プッシュ通知を有効にする</button> </body> </html> window.addEventListener('load', function() { document.getElementById('register').addEventListener('click', register, false); document.getElementById('push'

「モバイルブラウザで画面の縦長・横長を検出する方法を再確認してみた」の最後の方で触れましたが、window.orientationに代わる、端末の画面の向きを検出するためのAPIとして、新たにScreen Orientation APIの仕様策定が進んでいます。 Internet Explorer 11 (Windows 8以降), Firefox for Android, Chrome for Androidで実装されていますので、早速試してみます。なお、Chrome for Androidの実装はW3Cドラフトの最新版に基づいていますが、Firefoxの実装は一つ前のバージョンのドラフト、IE11の実装はさらに一つ前のバージョンのドラフトに基づいているようです(2015年1月14日現在)。 本記事では最新版の仕様に限定して説明します。 画面の向きを取得 Screen Orientati

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

※ visibilitychangeへの言及を修正いたしました。 ※ iOS 8.1以降の変更かもしれませんが、いつの間にか、Safariをバックグラウンドに移したり、端末がスリープしたりするくらいでは、WebSocketが勝手に切られたりはしなくなったようですね...。何のために苦労してこんな記事を書いてしまったのだろう... はじめに iOS向けにWebSocketを使うWebアプリを書いていたら、端末放置中にロック画面になったのでロック解除してSafariに戻ってみたら...問答無用でWebSocketが切断されましたとさ、という目に遭ってムッとしてしまったので、せっかくなので色々とまとめてみようかと思いまして。 Safariを使う場合とUIWebViewでの埋め込みWebアプリでの両方について書いてみます。(後者は条件によって色々変わるかもしれませんが...) WebSocket

ショッキングな出来事 以前、Qiitaに投稿した記事「モバイルブラウザで画面の縦長・横長を検出する方法を再確認してみた」にて、iOSとAndroidで画面回転時に発生するイベントの順序について触れたのですが... iOS 8では、また変わってしまっています... おさらい iOS 7.x以前の場合は、画面リサイズが完了してから、orientationchangeやresizeといったイベントが発生する。 Androidの場合は、orientationchangeイベント→画面リサイズ→resizeイベント、といった順序で処理が行われる。 Safari for iOS 8では iOS 8では、resizeイベント発生→orientationchangeイベント発生→画面回転・リサイズの順序で処理が行われる。 そして、resizeイベントの段階ではwindow.orientationの値が回転

モバイルブラウザのビデオ再生でアプリキャッシュが使えるかを再度検証で紹介したように、Androidのブラウザでは、アプリケーションキャッシュを使っても、<video>タグでデータを先読みしてタップしたら直ちに再生する、といった挙動を実現することができませんでした。 そこで、少し手の込んだ方式になってしまいますが、Chrome等でサポートされている、Media Source Extensionsを使って、キャッシュされたWebMファイルをXMLHttpRequestでロードして<video>タグで再生してみます。 なお、だったらXMLHttpRequestでデータを取得してBlobを生成すればいいのではないか、という声も聞こえてきそうですが、残念ながら、これもまたモバイルブラウザでは上手く行かなかったりします。 Media Source Extensionsの予備知識 そもそも、Media

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?

※ iOS 8での挙動に関連して追加情報を書いてみました: Safari for iOS 8での画面回転とイベント はじめに モバイルブラウザ(iOS SafariやAndroid標準ブラウザ、Chrome for Androidなど)で、WebアプリのJavaScriptから端末画面が縦長(portrait)と横長(landscape)のどちらを向いているかを調べる方法は、Web上で検索すると色々出てくるのですが、特にAndroid対応を考えると、例えば「au開発者情報Blog: CSS3 MediaQueries で端末回転方向によるレイアウト切り替えができない」辺りに書いてあるように、やってみると上手くいかないことが色々と出てきたりするように思えます。 注意事項(参考) 厳密には、window.orientationやorientationchangeイベントは、現在はあくまでもベン