このページは Cloud Translation API によって翻訳されました。

Linux 用のセルフホスト

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

パッケージ

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

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

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

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

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

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

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

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

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

[Extension root directory] フィールドに拡張機能のフォルダのパスを指定し、[PACK EXTENSION] ボタンをクリックします。初回パッケージの場合は、[秘密鍵] フィールドは無視します。

拡張機能のパスを指定し、[拡張機能をパッケージ化] をクリックします。

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

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

秘密鍵を紛失しないでください。.pem ファイルは非公開で安全な場所に保管してください。拡張子の更新が必要になります。

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

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

{
  ...
  "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 を確認します。それぞれについて、その URL にリクエストを送信し、更新マニフェスト XML ファイルを探します。

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

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

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

URL を更新する

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

{
  "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: "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
- バージョン: "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

1 つのリクエストで、一意の更新 URL ごとに複数の拡張機能を指定できます。上記の例では、ユーザーが両方の拡張機能をインストールしている場合、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 に自動更新されるようになります。