Linux 用のセルフホスト

Linux は、Chrome ユーザーが Chrome ウェブストア以外の場所でホストされている拡張機能をインストールできる唯一のプラットフォームです。この記事では、汎用ウェブサーバーから crx ファイルをパッケージ化、ホスト、更新する方法について説明します。拡張機能やテーマを Chrome ウェブストアのみで配布する場合は、ウェブストアでのホスティングと更新をご覧ください。

パッケージ

拡張機能とテーマは .crx ファイルとして提供されます。Chrome デベロッパー ダッシュボードからアップロードすると、ダッシュボードで crx ファイルが自動的に作成されます。個人用サーバーで公開する場合は、crx ファイルをローカルで作成するか、Chrome ウェブストアからダウンロードする必要があります。

Chrome ウェブストアから .crx をダウンロードする

拡張機能が Chrome ウェブストアでホストされている場合は、デベロッパー ダッシュボードから .crx ファイルをダウンロードできます。[出品] で拡張機能を見つけて、[詳細] をクリックします。ポップアップ ウィンドウで、青色の main.crx リンクをクリックしてダウンロードします。

デベロッパー ダッシュボードから .crx をダウンロードする

ダウンロードしたファイルは、個人用サーバーでホストできます。拡張機能の内容は Chrome ウェブストアによって署名されるため、これが拡張機能をローカルでホストする最も安全な方法です。これにより、潜在的な攻撃や改ざんを検出できます。

ローカルで .crx を作成する

拡張機能ディレクトリは、拡張機能管理ページで .crx ファイルに変換されます。アドレスバーで chrome://extensions/ に移動するか、Chrome メニューをクリックして [その他のツール] にポインタを合わせ、[拡張機能] を選択します。

拡張機能管理ページで、[デベロッパー モード] の横にある切り替えスイッチをクリックして、デベロッパー モードを有効にします。[拡張機能をパッケージ化] ボタンを選択します。

[デベロッパー モード] にチェックが入っていることを確認し、[拡張機能をパッケージ化] をクリックします。

[拡張機能のルート ディレクトリ] フィールドに拡張機能のフォルダのパスを指定し、[拡張機能をパッケージ化] ボタンをクリックします。初めてパッケージを作成する場合は、[秘密鍵] フィールドは無視してください。

拡張機能のパスを指定して [拡張機能をパッケージ] をクリックする

Chrome は、拡張機能の秘密鍵を含む .crx ファイルと .pem ファイルの 2 つのファイルを作成します。

パッケージ化された拡張機能ファイル

秘密鍵を紛失しないようにしてください。.pem ファイルは秘密で安全な場所に保管してください。拡張機能を更新する際に 必要になります。

.crx パッケージを更新する

拡張機能の .crx ファイルを更新するには、manifest.json のバージョン番号を増やします。

{
  ...
  "version": "1.5",
  ...
  }
}
{
  ...
  "version": "1.6",
  ...
  }
}

拡張機能管理ページに戻り、[**拡張機能をパッケージ化**] ボタンをクリックします。拡張機能ディレクトリのパスと秘密鍵の場所を指定します。

拡張ファイルの更新

更新されたパッケージ化された拡張機能のパスが表示されます。

拡張ファイルの更新

コマンドラインでパッケージ化する

コマンドラインで拡張機能をパッケージ化するには、chrome.exe を呼び出します。--pack-extension フラグを使用して拡張機能のフォルダの場所を指定し、--pack-extension-keyフラグを使用して 拡張機能の秘密鍵ファイルの場所を指定します。

chrome.exe --pack-extension=C:\myext --pack-extension-key=C:\myext.pem

ホスト

.crx ファイルをホストするサーバーでは、ユーザーがリンクをクリックして拡張機能をインストールできるように、適切な HTTP ヘッダーが使用されていなければなりません。

Google Chrome では、次のいずれか の条件を満たすファイルはインストール可能と見なされます。

  • ファイルのコンテンツ タイプが application/x-chrome-extension である
  • ファイルのサフィックスが .crx で、次の両方 が当てはまる。
    • ファイルが HTTP ヘッダー X-Content-Type-Options: nosniff で提供されていない
    • ファイルが次のいずれかのコンテンツ タイプで提供されている
    • 空の文字列
    • "text/plain"
    • "application/octet-stream"
    • "unknown/unknown"
    • "application/unknown"
    • "\*/\*"

インストール可能なファイルが認識されない最も一般的な理由は、サーバーがヘッダー X-Content-Type-Options: nosniff を送信することです。2 番目に多い理由は、サーバーによる未知のコンテンツ タイプ、つまり前のリストにないコンテンツ タイプの送信です。HTTP ヘッダーの問題を修正するには、サーバーの設定を変更するか、別のサーバーで .crx ファイルをホストしてみます。

更新

ブラウザは数時間ごとに、インストールされている拡張機能の更新 URL を確認します。各拡張機能について、更新マニフェスト XML ファイルを探してその URL にリクエストを送信します。

  • 更新チェックで返されるコンテンツは、拡張機能の最新バージョンを一覧表示する更新マニフェスト XML ドキュメントです。

更新マニフェストにインストールされているバージョンよりも新しいバージョンが記載されている場合、ブラウザは新しいバージョンをダウンロードしてインストールします。手動更新と同様に、新しい .crx ファイルは、現在インストールされているバージョンと同じ秘密鍵で署名する必要があります。

注: ユーザーのプライバシーを保護するため、Google Chrome は自動更新マニフェスト リクエストとともに Cookie ヘッダーを送信せず、これらのリクエストに対するレスポンスの Set-Cookie ヘッダーを無視します。

URL を更新

Chrome ウェブストア以外のサーバーでホストされている拡張機能には、update_url フィールドを manifest.json ファイルに含める必要があります。

{
  "name": "My extension",
  ...
  "update_url": "https://myhost.com/mytestextension/updates.xml",
  ...
}

マニフェストを更新する

サーバーから返される更新マニフェストは XML ドキュメントである必要があります。

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'>
    <updatecheck codebase='https://myhost.com/mytestextension/mte_v2.crx' version='2.0' />
  </app>
</gupdate>

この XML 形式は、Google の更新インフラストラクチャである Omaha で使用されている形式を基にしています。拡張機能システムでは、更新マニフェストの <app> および <updatecheck> 要素に次の属性を使用します。

appid
拡張機能 ID は、パッケージ化の説明に従って、公開鍵のハッシュに基づいて生成されます。拡張機能の ID は、拡張機能管理ページに表示されます。
コードベース
.crx ファイルへの HTTPS URL。
version
クライアントが codebase で指定された .crx ファイルをダウンロードするかどうかを判断するために使用されます。.crx ファイルの manifest.json ファイルの「version」の値と一致する必要があります。

更新マニフェスト XML ファイルには、複数の拡張機能に関する情報を含めることで、複数の <app> 要素を含めることができます。

テスト

デフォルトの更新チェックの頻度は数時間ですが、拡張機能管理ページの [拡張機能を今すぐ更新] ボタンを使用して、更新を強制的に行うことができます。

拡張機能を今すぐ更新

これにより、インストールされているすべての拡張機能のチェックが開始されます。

高度な使用方法: リクエスト パラメータ

基本的な自動更新メカニズムは、サーバーサイドの作業を、静的な XML ファイルを Apache などのプレーンなウェブサーバーにドロップし、新しい拡張機能バージョンがリリースされたときにその XML ファイルを更新するだけで済むように設計されています。

複数の拡張機能をホストしているデベロッパーは、更新リクエストの拡張機能 ID とバージョンを示すリクエスト パラメータを確認できます。これらのパラメータを含めることで、拡張機能は静的な XML ファイルではなく、動的なサーバーサイド コードを実行する同じ URL から更新できます。

リクエスト パラメータの形式は次のとおりです。

?x=EXTENSION_DATA

EXTENSION_DATA は、次の形式の URL エンコードされた文字列です。

id=EXTENSION_ID&v=EXTENSION_VERSION

たとえば、2 つの拡張機能が同じ更新 URL(https://test.com/extension_updates.php)を指しているとします。

  • 拡張機能 1
    • ID: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
    • バージョン: "1.1"
  • 拡張機能 2
    • ID: "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
    • バージョン: "0.4"

個々の拡張機能を更新するリクエストは次のようになります。

https://test.com/extension_updates.php?x=id%3Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%26v%3D1.1

https://test.com/extension_updates.php?x=id%3Dbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb%26v%3D0.4

一意の更新 URL ごとに 1 つのリクエストで複数の拡張機能を一覧表示できます。前の例で、ユーザーが両方の拡張機能をインストールしている場合、2 つのリクエストは 1 つのリクエストに統合されます。

https://test.com/extension_updates.php?x=id%3Daaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa%26v%3D1.1&x=id%3Dbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb%26v%3D0.4

同じ更新 URL を使用するインストール済み拡張機能の数が多く、GET リクエスト URL が長すぎる場合(2,000 文字以上)、更新チェックでは必要に応じて追加の GET リクエストが発行されます。

高度な使用方法: ブラウザの最小バージョン

拡張機能システムに API が追加されると、新しいバージョンのブラウザでのみ動作する拡張機能の更新バージョンがリリースされることがあります。Google Chrome 自体は自動更新されますが、ユーザーベースの大部分が特定の新しいリリースに更新されるまでに数日かかることがあります。特定の更新が特定のバージョン以上の Google Chrome バージョンにのみ適用されるようにするには、更新レスポンスの <app> 要素に「prodversionmin」属性を追加します。

<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
  <app appid='aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'>
    <updatecheck codebase='http://myhost.com/mytestextension/mte_v2.crx' version='2.0' prodversionmin='3.0.193.0'/>
  </app>
</gupdate>

これにより、ユーザーが Google Chrome 3.0.193.0 以降を実行している場合にのみ、バージョン 2 に自動更新されます。