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

Linux への拡張機能のインストール

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

パッケージング

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

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

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

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

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

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

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

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

[デベロッパーモード] のチェックボックスをオンにして、[拡張機能パック] をクリックする

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

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

Chrome は .crx ファイルと .pem ファイルという 2 つのファイルを作成します。このファイルには拡張機能の秘密鍵が含まれています。

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

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

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

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

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

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

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

拡張機能ファイルの更新

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

拡張機能ファイルの更新

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

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"
- 「不明/不明」
- 「application/unknown」
- "*/*"

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

更新中

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

アップデートチェックによって返されるコンテンツは、拡張機能の最新バージョンがリストされたアップデートマニフェストの 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。
バージョン	`codebase` で指定された `.crx` ファイルをダウンロードする必要があるかどうかを判断するためにクライアントが使用します。`.crx` ファイルの `manifest.json` ファイルにある「version」の値と一致する必要があります。

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

テスト

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

今すぐ拡張機能を更新

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

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

基本的な自動更新のメカニズムは、Apache などのプレーンなウェブサーバーに静的 XML ファイルをドロップし、新しい拡張機能バージョンがリリースされるたびにその 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: "bbbbbbbbbbbbbbbbbbbbbbbbbbbbbb"
- バージョン: 「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 バージョンにのみ適用するには、アップデートの応答の要素に「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 に自動更新されます。