0

問題:localhostで開発するときにURLをリダイレクトする最良の方法は何ですか?

私は2つのWebアプリケーションを持っている、そして "App1のは" ajax.In制作を経て、 "App2の" からデータを取り出し、App1のはApp2のために生産されたURLからデータをフェッチする必要があります。しかし、私がlocalhost:3000上でApp1を開発しているとき、App1のローカルバージョンからlocalhost:3001(実稼働バージョンではない)でデータを取得します。

前研究:

私はこれを行う方法のためにたくさんの周りに検索したが、実際に私が見つけたものの頭や尾をすることはできません。

  • 私は、/ etc/hostsファイルを変更する必要があります示唆いくつかのことを読んだが、私は、本番サイトがHTTPSを使用しているため、作業が、私はlocalhostのみがHTTPであることを取得することができていません。

  • 私はまた、.htaccessに出くわしましたが、ファイルを追加しても効果がないようで、Apacheのウサギの穴でかなり失われてしまいました。 (私はmod-rewriteについてもいくつかのことを見てきましたが、その方法を理解する方法はわかりません)Switcheroo RedirectorのようなChrome拡張機能も見つかりましたが、うまく機能しませんでした。なぜなら、単純なリダイレクトは301の必須のHTTPレスポンスを変更するからです。これは私のアプリが扱うように設計されていないものです。

質問

  • 私がやろうとしている何のための適切なツールは何ですか? (/ etc/hosts、.htaccessなど)

  • 希望の結果を得るための最も基本的な設定は何ですか?

+0

実際にapp1が要求したURLをどうにか変更する必要があります。それのまわりには道がない。通常、そのようなURL(少なくともベースURL)は、アプリケーションの設定パラメータであり、パスにハードコードされていません。ですから、それを設定ファイルに置くこともできますし、より洗練された方法で、httpサーバからphpスクリプトに環境変数として渡すこともできます。次に、あなただけの書き換えのすべての手段をご利用いただけます。しかし、それがなければ、リクエストはあなたのローカルのHTTPサーバーにも届かず、何かをしようとするすべての試みは単に効果がありません。 – arkascha

+0

よろしくお願いします。ありがとうございました! –

+0

ああ、プロダクションシステム名をローカルアドレスに解決するには、ローカルホスト名の設定を変更するオプションがあります。次に、実稼働システム名でローカルのhttpサーバーに仮想ホストをローカルに構成し、自己署名証明書でhttpsをオンにする必要があります。それはうまくいくはずです。あなたのアプリだけがhttps接続用の自己署名証明書を受け入れる必要があるので、証明書の有効性を無効にする必要があります。 – arkascha

答えて

0

通常、実際にはapp1によって実際に要求されたURLを変更する必要があります。通常、そのようなURL(少なくともベースURL)は、ハードコードされていないアプリの設定パラメータです。ですから、それを設定ファイルに置くこともできますし、より洗練された方法で、httpサーバからphpスクリプトに環境変数として渡すこともできます。次に、あなただけの書き換えのすべての手段をご利用いただけます。しかし、それがなければ、リクエストはあなたのローカルのHTTPサーバーにも届かず、何かをしようとするすべての試みは単に効果がありません。

他のオプションは、ローカルホスト名の設定を変更して、そのapp2プロダクションシステム名をローカルIPアドレスに解決することです。次に、実稼働システム名でローカルのhttpサーバー内に仮想ホストを構成し、httpsをオンにする必要があります。 ssl暗号化には自己署名証明書を使用できます。それはうまくいくはずです。あなたのアプリだけがhttps接続用の自己署名証明書を受け入れる必要があるので、証明書の有効性を無効にする必要があります。

0

次のようなjqueryを使用して簡単なリクエストを行います。クエリhttp://api.jquery.com/jquery.ajax/

var url = "localhost:3001/cart/1"; 
$.ajax({ 
      url: url, 
      data: currentQueryData, 
      success: function(data) { 
       console.log("Data from App2 url: + data); 
       // Do something with your data 
      }, 
      failure: function(error){ 
       console.log(error); 
      } 
     }); 

でクエリAjaxリクエストのより多くの情報を参照してください。そして、あなたは生産に自分の開発したアプリで行く場合、要求は、生産App2のに比べて行くようにするには、単にプロパティurlに「https://api.app2.com」の値を変更します。 また、/ etc/hostsの設定ファイルを編集して、ローカルホストへの生産のURLをポイントし、それに次の行を追加することができます。

127.0.0.1 domain.app2.de 

しかし、あなたはあなたのJavaScriptファイルにそのドメインにポートを追加することが必要です。 Like

var url = "domain.app2.de:3001" 

ドメインを/ etc/hostsファイルの特定のポートにバインドすることはできないためです。 次のようなものは動作しません!

127.0.0.1:3001 domain.app2.de # not working 

希望します。エントリポイントのURLをあなたのapp2に保存することをお勧めします。それをjavascript値に格納することは、それがsiplefiedの例として行われる方法の目的を示すためだけです。それ以外の場合は、app2からフェッチしたいものを提供することができれば素晴らしいでしょう。

0

mod_proxy + mod_rewrite私は、メインドメイン上の単一のパス接頭辞を持つすべてのURLが内部的にapp2へのプロキシ要求に書き換えられるようにします。これにはいくつかの利点があります:

  1. フロントエンドをサーバーの設定で汚染することはありません。これは心配の良い分離を提供し、コードが開発者と生き方の間で違わないことを保証する。
  2. クライアントには、すべての要求が同じスキーム、ドメイン、およびポートに送信されるため、CORSの問題はありません。
  3. Ajax URLはroot-relativeである可能性があるため、よりクリーンです。 (あなたのすべてのURLである必要があります)
  4. 変更されていない同じ.htaccessファイルは、送信されたホストヘッダーに基づいて各アプリケーション2に条件付きで書き換えることができるため、開発サーバーとライブサーバーで使用できます。 (アクセス権があればあなたの仮想ホストに設定を入れておくべきですが)
  5. 同じ条件付きロジックを使用して、ライブでのみhttpsを適用することができます。
  6. ユーザを中断することなく、単一のルールを編集することによって、再配置/アップグレードのために異なるapp2サーバに切り替えることができます。

あなたのフロントエンドで、その後.htaccess

RewriteEngine on 
# force https and single domain on live 
RewriteCond %{HTTP_HOST} !=localhost 
RewriteCond %{HTTP_HOST} ^(?!real-app1\.com$). [NC,OR] 
RewriteCond %{HTTPS} =off 
RewriteCond %{THE_REQUEST} ^\S+\s+/(\S*) 
RewriteRule^https://real-app1.com/%1 [NS,NE,L,R=301] 
# API proxy on dev 
RewriteCond %{HTTP_HOST} =localhost 
RewriteCond %{THE_REQUEST} ^\S+\s+/API(?:/(\S*))? 
RewriteRule ^API(?:$|/) http://localhost:3001/%1 [NS,NE,P] 
# API proxy on live (no need for hostname check) 
RewriteCond %{THE_REQUEST} ^\S+\s+/API(?:/(\S*))? 
RewriteRule ^API(?:$|/) https://real-app2.com/%1 [NS,NE,P] 

でこれを行うと仮定すると、通常のリンクはちょうどあなたがライブラリを使用していると仮定すると、<a href="/foo/bar/">…を可能とすることができ、AJAXは、このように簡単することができ:

$.ajax('/API/path/to/endpoint/', { 
    data: { 
     query_param: 'param_value' 
    } 
}) 
.done(function() { 
    // API works 
}) 
.fail(function() { 
    // oh dear 
}); 

ここで、app2はhttp://localhost:3001/path/to/endpoint/?query_param=param_valueを受け取る必要があります。これを正しく設定する作業量は、アプリケーションのライフサイクルにおける設定や配備の問題を管理することの頭痛よりも少なくなります。間違いなく価値がある。

関連する問題