Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Chrome ウェブストア以外でホストされている拡張機能は、Linux ユーザーのみがインストールできます。この記事では、個人用サーバーから .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 ファイルには、拡張機能の秘密鍵が含まれています。

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

秘密鍵を紛失しないでください。.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> 要素を含めることで、複数の拡張機能に関する情報を含めることができます。

テスト

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

拡張機能を今すぐ更新

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

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

基本的な自動更新メカニズムは、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: "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 バージョンにのみ更新が適用されるようにするには、更新レスポンスの要素に「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 に自動更新されるようになります。