GitHub PagesのSSL環境でService Workerを試す
以下ではSSL環境の利用例として、HTML5の新技術であるService Workerを紹介します。Service Workerは、Webブラウザ本体とは別にバックグラウンドで実行できるスクリプトで、HTML5ウェブアプリケーションの利用範囲を大きく拡げるものと期待されています。Service WorkerはSSL環境でしか機能しないため、今回はGitHub PagesにWebコンテンツをプッシュして動作させます。
Service Workerで実現するオフラインキャッシュ
今回はService Workerでオフラインキャッシュの機能を実現してみます。HTML5でオフラインキャッシュを実現する機能としては従来AppCacheが存在しましたが、Service Workerはより柔軟なキャッシュ機能を実現します。
Service Workerを利用するためには、まずリスト3のようにregisterメソッドでService Workerを登録する必要があります。ここではservice-worker.jsを登録しています。
// Service Workerを登録 navigator.serviceWorker.register("./service-worker.js") .then(function(registration){ // 登録成功 document.getElementById("msg").textContent = "Service Worker 登録成功"; }).catch(function(error) { // 登録失敗 document.getElementById("msg").textContent = "Service Worker 登録失敗:" + error.toString(); });
登録されるservice-worker.jsの内容をリスト4に示します。
// 現行Chromeで実装されていないCache APIを補うライブラリ ...(1) importScripts("serviceworker-cache-polyfill.js"); // キャッシュ対象ファイル ...(2) var urlsToCache = [ ".", "index.html", "img/image1.jpg", "img/image2.jpg", "img/image3.jpg", "img/image4.jpg" ]; // キャッシュ名 ...(3) var CACHE_NAME = "swsample-cache-v1"; /** * Service Worker登録直後のハンドラ ...(4) */ self.addEventListener("install", function (event) { event.waitUntil( // キャッシュオープン ...(5) caches.open(CACHE_NAME).then(function (cache) { console.log("opened cache"); // キャッシュ対象ファイルをキャッシュ ...(6) var result = cache.addAll(urlsToCache); return result; }) ); }, false); /** * Webリクエストのハンドラ ...(7) */ self.addEventListener("fetch", function (event) { event.respondWith( caches.match(event.request).then(function (response) { // キャッシュヒットした時にはキャッシュを返却 ...(8) if (response) { return response; } // キャッシュヒットしない時にはネットワークから取得 ...(9) return fetch(event.request); }) ); }, false);
(1)はブラウザで実装されていないHTML5 Cache APIのaddAllメソッドを補完するライブラリです。(2)はキャッシュ対象のファイル、(3)はキャッシュの名前です。Service Workerが登録されるとinstallイベントが発生するので(4)、そのタイミングでキャッシュ名を指定してキャッシュを開き(5)、addAllメソッドでファイルをキャッシュしています(6)。
一方、Webページのリクエストがあるとfetchイベントが発生するので(7)、リクエストに対応するキャッシュがあればそれを返し(8)、なければネットワークから取得して返します(9)。
リスト3、4を含むWebページをGitHub Pagesにアップロードしてhttps://~でアクセスしてWebブラウザで表示させます。その後機内モードにしてページをリロードしても、キャッシュからページを読み込むためエラーにならず表示されます。
![図8 Service Workerでキャッシュを表示(機内モードになっていることに注目)](http://cz-cdn.shoeisha.jp/static/images/article/8889/8889_008_s.gif)
使い方によっては危険なService Workerの機能をSSLで保護
ここでService WorkerとSSLの関係を説明します。例えばリスト4の(8)ではリクエストに対して対応するキャッシュを返していますが、リクエストとは全く別のコンテンツを返すことも理論上可能です。そのため悪意のあるService Worker実装が紛れ込むと、コンテンツの改ざんのようなセキュリティ問題につながります。このように強力かつ危険な機能を安全に使うため、Service WorkerはSSL環境だけで利用可能になっているわけです。
まとめ
本記事では、安全なWeb通信を実現するSSLの概要と、それを取り巻く情勢について紹介しました。SSL自体は決して新しい技術ではありませんが、近年のセキュリティリスク向上を受けてSSLの重要度は増しています。またIT業界全体としてもSSLを必要とする技術が増えてきている現状があり、新しく便利な技術を存分に活用するためにSSL環境を整備する必要が出てきています。本記事ではSSL環境整備の助けとしてLet's EncryptとGitHub Pagesを紹介しました。
記事の後半で紹介したService WorkerはWebアプリケーションにバックグラウンド処理を提供します。今回紹介したコンテンツキャッシュのほか、プッシュ通知やバックグラウンドでのコンテンツ同期など、よりネイティブアプリに近いWebアプリを実現する強力な機能を提供します。強力な機能を安全に使うため、Service WorkerはSSL環境でなければ使えないことを紹介しました。今後はこのようにSSL限定で提供される機能は増えていくと思われます。