運用Webサイトを取得して、ローカルWebサーバーからアセットをロードするにはどうすればよいですか？

Question

JavaScriptを使用して新しい機能を開発するときは、通常、マシン上でWebサイトを実行するローカル環境をセットアップします。スタイルシートの更新についても同じことが言えます。

実稼働サイトをローカルで実行する簡単な方法がない場合でも、ファイルをローカルで編集し、ライブサイトに対して「プレビュー」することを希望します。このようなもの：

アセット（cssおよびjs）を提供するローカルWebサーバー
ライブWebサイトにmy local Webサーバーからアセットをロードさせる方法。（Greasemonkey、プロキシ）
ローカルファイルを監視し、変更時にライブサイトを更新するLivereload。

秒のステップに関するフィードバックが必要です。 GreasemonkeyはFirefox専用であるため、クロスブラウザー機能をテストするのは困難です。プロキシは多くの作業です... :)

誰かが似たようなことを試しましたか、おそらくこれのためのスマートなツールがありますか？

Nick · Accepted Answer

ローカルマシン上のアセットのリクエストのみをリダイレクトするには

リモートサーバーからリクエストされた特定のJavaScriptまたはCSSアセットにローカルファイルを使用するようにローカルマシンを取得するには、 Charles などのHTTPプロキシ/傍受ツールを使用できます。（Mac、Windows、およびLinux。30日間のデモ、その後50ドルで購入できます。）

リモート要求をリッスンし、代わりにローカルファイルを提供するようにCharlesをセットアップするには、次の手順を実行します。

Charlesのダウンロード。
Charlesを起動し、プロンプトが表示されたら、プロキシ設定を変更します。
ブラウザでテストしているWebサイトにアクセスします。この例では、Chromeを使用してGoogleにアクセスしています。
左ペインのCharlesの「構造」ウィンドウでWebサイトを検索し、フォルダーをドリルダウンして、変更する要求されたアセットにドリルダウンします。この例では、Googleのロゴを使用しています。
アセットを2回クリックして、オプションから「ローカルにマップ」を選択します。
リモートアセットの代わりにローカルファイルシステムからロードするファイルを選択します。
再マッピングするアセットの数だけ繰り返します。
ブラウザを強制的に更新します。アセットは、リモートマシンではなくローカルマシンからロードされるはずです。

リモートファイルが再度読み込まれるようにローカルファイルを「マッピング解除」するには、次の手順を実行します。

Charlesのメニューから[ツール]> [ローカルにマップ]を選択します。
リストから削除するルールをクリックし、「削除」ボタンをクリックします。

WebScarab や Burp suite など、同じことができる無料のアプリケーションがありますが、どちらもCharlesほど簡単でも美しいものでもありません。。

この回答の残りは、リモートWebサーバーがリモートサイトにアクセスするすべてのユーザーのコンピューターからファイルをロードする場合に実行する手順に関するものです。（ユースケースの例：運用サイトをローカルで再現できない場合や開発サーバーをステージングできない場合にクライアント/同僚に作業を表示する。）

すべてのマシン上のアセットのリクエストをリダイレクトするには

別のリモートWebサーバーにアクセスするすべてのマシンに対してローカルマシンから特定の資産を提供するために、Webからアクセスできるようにローカルサーバーを設定できます。いくつかのオプション：

ローカルホストトンネリングサービス

これらのサービスは、ウェブ上でローカルホストを共有し、ウェブアドレスを介してアセットまたはサイト全体を利用できるようにします。

Showoff.ioとTunnlrは月額5ドルの有料サービスです。 Localtunnelは現在無料です。

ダイナミックDNS

無料の代替手段は、 afraid.org などのサービスからの動的DNSホスティングを使用して、ローカルマシンで実行されているWebサーバーでWebアドレスを指すことです。仕組みは次のとおりです。

afraid.orgでサインアップ。
送信するメールのリンクをクリックして、アカウントを有効にし、自動的にログインします。
新しいサブドメインを設定します。これを使用して、Webからローカルホストにアクセスします。無料ドメイン（「mooo.com」など）のいずれかを選択できます。自分で登録する必要はありません。
ご使用のオペレーティングシステム用の多くの動的DNSアプリケーションのいずれかをダウンロードします。
IPアドレスをafraid.orgサーバーに公開するアプリケーションを実行します。
ローカルマシンのポート80で実行するようにサーバーを設定し、実行しているファイアウォールのポート80を介したトラフィックを許可します。これを行う方法は、オペレーティングシステムとハードウェアによって異なります。（たとえば、Mac OS Xを使用している場合は、[システム環境設定]> [共有]ペインで[ウェブ共有]をオンにするだけで済みます。）
Webブラウザで手順3で作成したサブドメインにアクセスします。（例：yourname.mooo.com）。名前はマシンのIPアドレスに解決され、サーバーとファイアウォールが正しく構成されていれば、ローカルマシンのインデックスファイルが表示されます。

次に、作成したafraid.orgサブドメインでそれらのアセットへのフルパスを使用することにより、Web経由でローカルマシンのパブリックフォルダー内のアセットにアクセスできます。例：yourname.mooo.com/~yourMacUsername/images/hurrah.jpg当然、別のサーバーからそのURLを参照して、ローカルマシンからファイルをロードすることができます。

[Macでは、パブリックフォルダーはユーザーディレクトリの「サイト」フォルダーです。アクセスするには、IPアドレスまたはホスト名に続けてチルダ（〜）とMacユーザー名を使用します。他のサーバーとオペレーティングシステムの動作は少し異なります。]

MrWhite · Answer

外部リダイレクト

本番.htaccessファイルの編集に問題がなければ、必要な静的アセットのリクエストをローカルWebサーバーにリダイレクトするだけで済みます。リダイレクトは、サイトにアクセスするIPアドレス（つまり、外部IPアドレス）を条件とします。

たとえば、特定のアセットをローカルサーバー上の同じURLパスにリダイレクトするには：

RewriteEngine On RewriteCond %{REMOTE_ADDR} ^203\.0\.113\.111$ RewriteRule ^assets/main\.css$ http://local-web-server.com%{REQUEST_URI} [R,L]

すべてのCSSファイル：

RewriteRule ^assets/.+\.css$ http://local-web-server.com%{REQUEST_URI} [R,L]

すべての資産：

RewriteRule ^assets/.+ http://local-web-server.com%{REQUEST_URI} [R,L]

解決可能なホスト名（例：local-web-server.com）を使用する必要はありません。ローカルWebのローカルIPアドレスを使用するだけです。サーバー（例：192.168.1.20）。ただし、ホスト名を使用すると、ローカル開発サーバーは仮想ホストを使用して、プロジェクト間で何も変更することなく複数のWebサイトを提供できます。

上記は一時的な（302）リダイレクトです。 RをR=301に変更することにより、これらを永続（301）に変更できます。これにより、ブラウザがキャッシュからリダイレクトするため、サーバーリクエストが減少します。ただし、キャッシュされたリダイレクトをクリアするには、完了時にローカルブラウザのキャッシュをクリアする必要があります。

欠点：

プロダクション.htaccessファイルにアクセスして編集する必要があります。
外部リダイレクトです。ライブコンテンツを提供するためにこれを行うことはありませんが、ローカルテストでは完全に問題ありません。

利点：

ローカル開発サーバーはパブリックである必要はありません。
開発マシンのすべてのブラウザーで機能します。
DNSがlocal-web-server.com（WebサーバーのローカルIPアドレスを指す）に対してパブリックである場合、誰でも（または任意のデバイス）ローカルネットワークもこれらのローカル資産を見ることができます。

静的アセットの個別のホスト名

実稼働サイトがすべての静的アセットに個別のホスト名を使用している場合（例： static.example.comを選択すると、ローカルDNS（HOSTSファイル）でこれをオーバーライドして、代わりにローカル開発サーバーを指すようにすることができます。

欠点：

ローカルネットワーク用の中央集中型DNSサーバーがない場合、ローカルネットワーク上の他のデバイスは、独自のHOSTSファイルを変更しない限り、ローカル資産を見ることができません（モバイルデバイスでは常に可能とは限りません）。

利点：

本番サーバーでサーバー側の変更は必要ありません。

逆プロキシ

これをシームレスにする（リダイレクトしない）ために、実稼働サーバーでリバースプロキシを構成できます。 .htaccessには、必要なアセットをプロキシするための同様のディレクティブがまだあります。

欠点：

リバースプロキシを構成するには、運用サーバーにアクセスする必要があります。
要求をプロキシするために運用サーバーにアクセスする必要があります（おそらく[.htaccess）。
ローカル開発サーバーは「パブリック」である必要があります。

利点：

remoteユーザーが完全な「開発」サイトを表示できるようにすることができます。

ローカルファイルを監視し、変更時にライブサイトを更新するLivereload。

それは本当に別の問題です。最近の多くのコードエディタには、この機能を有効にする「ライブプレビュー」機能/プラグインがあります。