アクセスが制限されたMagentoステージング環境のセットアップ


18

アクセス制限のあるステージング環境をセットアップする最良の方法を見つけようとしています。

簡単な解決策は基本認証をスローすることですが、パフォーマンスの最適化や、アクセスしたい他の同様の外部サービスをテストする際に、Google Page Speed Insightsを指すことはできません。

robots.txtで完全に公開して、検索エンジンに表示されないようにすることができます。しかし、私の懸念は、robots.txtの間違いのリスクがかなり高いことであり、それについて心配する必要はありません。

検索エンジンをブロックしない場合(または一部が検索エンジンを無視する場合)、ライブの顧客がステージングサイトに注文するようになります。

さらに悪いことに、robots.txtを本番環境に誤って展開すると、Googleのすべてのジュースと大量の売り上げを失うことになります。

したがって、私が気に入っているオプションは、単純なIPアドレスの制限です。ただし、変更を行う際のリスクを最小限に抑えるために、Nginxを再起動せずに制限を追加/削除できるようにしたいと考えています。

そのため、有効にすると開発者のIPアドレスを調べ、ユーザーのIPアドレス(またはX_FORWARDED_FOR)が一致した場合にのみサイト(フロントおよびバックエンド)へのアクセスを許可するクイックモジュールに傾倒し始めています。

これが合理的な解決策のように聞こえるか、私が見逃しているより簡単なものがあるかどうか疑問に思います。

更新:robots.txtがネイティブバックエンドスイッチを介して制御でき、デモストアの通知により正当な顧客注文が妨げられることを考えると、ステージングサイトへのパブリックアクセスについては本当に心配していないので、Philのソリューションが好きです。

しかし、ステージングサイトへのアクセスを制限したい人にとっては、Krisのソリューションが道だと思います。

更新2:robots.txtオプションがSystem Config> Design> HTML Headで何をすべきか100%確信していませんが、私の場合-そして簡単な検索からこれは一般的であるように見えます-私はちょうどフラットrobots.txtを持っています使用されている場所にテキストファイルがあるため、configオプションは尊重されません。

だから、私は今のところメンテナンスモジュールに行きます:https : //github.com/aleron75/Webgriffe_Maintenance

回答:


6

いくつかの提案-いくつかは組み込まれています!

- 開発者IP制限は、システム構成>開発者に組み込まれています:

これはIPアクセスを制限しません。一緒に移動。

  • IP制限は厳しく、私は個人的にファイアウォールでこれを処理することを好みます。IPテーブルも、htaccessの制限または$_SERVER['REMOTE_ADDR']index.php 経由での候補です。

  • System Config> Design> HTML Headのステージング中に、CMS のデフォルトのページごとのロボットメタをNOINDEX / NOFOLLOWに更新します

ここに画像の説明を入力してください

  • 同じ設定エリアに、デモストアの通知表示する機能があります

ここに画像の説明を入力してください


1
おかげでフィル。ロボットがデフォルトのバックエンドオプションであることを忘れていたので、robots.txtファイルを手動でいじり回すよりも、それを使用する方が少しリスクが少ないと思います。開発者のIP制限を実際に知っていましたが、実際にはサイトへのアクセスを制限する助けにはなりませんよね?開発者向け機能のみですか?そしてデモ通知-間違いなく、顧客が誤って注文するのを避けるべきです、良い電話。
-kalenjordan

1
そうだね。どうしてそれを知らなかったのか分かりません。
-philwinkle

11

(ほとんどの)ステージング環境をロックダウンする主な手段は、BASIC認証です。ただし、公開Webサイトにリンクが表示されないように(これは決して起こりません)、エンジンによって検出されたり、Googleによってインデックスに登録されたりするのを防ぐための予防策も用意されています。

/etc/httpd/conf.d/robots.conf次のエイリアスを使用してルールを設定しました。

Alias /robots.txt /<path_to_public_html>/robots.txt
<Location /robots.txt>
  Satisfy any
</Location>

エイリアスは、robots.txtの場所へのすべてのリクエストをロックダウンされたファイルにルーティングします。つまり、Magentoステージングルートのrobots.txtファイルに何があっても、サーバーは常に次のルールを提供します。

User-agent: *
Disallow: /

グローバルなdisallow from anyルールがないため、場所と満足度を指定すると、認証に関係なく、robots.txtファイルを誰にでも提供できます。

パスワード認証の場合Satisfy any.htaccessファイルに追加することで一時的に単一のサイトで認証を開くことができるようにルールが設定されています。これは、同じ専用の内部ステージングサーバーで複数のステージサイトを実行しているためです。また、特定のIPアドレスへのパスワード認証を削除するallow fromとともに、Satisfy any他のすべてのユーザーに対してそれを維持しながら、ルールを設定することもできます(本当に必要な場合)。

私が全面的にIPベースのホワイトリストを好まない理由(つまり、パスワードベースの認証なし)は、クライアントのIPアドレスが常に静的ではないためです。つまり、ISPのDHCPがリースを保持している期間に応じて、(潜在的に)毎日または毎週アクセスするために、IPを更新する必要があります。

DNSの場合、ワイルドカードDNSを使用して、DNSクローラーがパブリックDNSを必要とするすべてのステージサイトホスト名をピックアップしないようにします。Googleは実際にDNSレコードからサイトを選択します。これはそれを防ぎます。つまり、誰かがどこかにリンクを残した場合にそれを見つける唯一の方法です。ただし、ロボットファイルに不許可ルールを強制的に適用すると、リンクが見つかった場合にインデックス作成を停止します。

会社のWebサイトのステージサイトを運営している商人の場所にいた場合、少し違う方法で、既知のIPアドレスが来ない限り、ステージボックスに来るすべてのトラフィックをまっすぐにブロックします。ホワイトリストに登録できる静的IPがない場合、サイトでリモート(社内)で作業している人は、会社のVPNに接続してアクセスする必要があります。

ほとんどのゲートウェイとは異なり、支払いプロセスを実行するためにサーバーへのコールバックを行う必要がある支払いプロセッサ統合などをテストする必要がある場合、パブリックDNSが必要です。


2
これは本当に思慮深い。ただし、基本認証も使用しますが、ほとんどの場合、上記のステージングに同じ課題があります:支払い処理者など
philwinkle

6

前面にアクセスするユーザーをブロックするのと同じ効果で使用できるメンテナンスモードを有効にするモジュールを開発しました(MagentoのネイティブIPブロック機能で制限できる管理者ではありません)。

メンテナンスモードが有効な場合でも、一部のIPがフロントエンドにアクセスできるようにすることができます。

たぶん、あなたはそれが助けになることを望んで、それを試してみることができます。無料でオープンソースです:https : //github.com/aleron75/Webgriffe_Maintenance


+1いいね!これはまさに私が念頭に置いていた種類のモジュールです。Varnishの背後でテストしましたか?
kalenjordan

こんにちは、残念ながら、ワニスの後ろでテストしませんでした、ごめんなさい。あなたはそれをしますか?;-)
アレッサンドロロンキ

ステージング環境で作業しています。このロジックがb / cで機能するかどうかはわかりREMOTE_ADDRませんでしたが、正しいアドレスではないので REMOTE_ADDRまたはのいずれかと比較する方が良いと思いますX_FORWARDED_FOR。しかし、ステージングでうまく動作しているので、私自身はまだ自分で掘り下げることをあまり心配していません。
-kalenjordan

4

これにはいくつかの異なる方法があります。

1つの方法は、開発者に/ hostsファイルを正しいIPアドレスで編集させることです。

よりエレガントな方法でこれを行うと主張する拡張機能がありますhttp : //www.magentocommerce.com/magento-connect/et-ip-security.html


1
クリスありがとう!デモストアの機能を使用することについて考えているので、私はちょうどそれを使用することに傾いていると思います。robots.txtを手作業でぶらぶらしたり、デモストアに通知したりする必要はないので、それで十分だと思います。しかし、ステージングへのアクセスを制限したい人にとっては、あなたが見つけたモジュールが道だと思います。ありがとう!!
kalenjordan

2

コメントでVarnishについて尋ねたので、例外を含め、Varnishを使用してHTTP基本認証と設定を共有します。VCLで設定する必要があります。そうしないと、キャッシュされたページに常にアクセスできます。

ニスVCL構成

VCLファイルの先頭でACLとして定義する、支払いプロバイダーなどのコールバックに特定のIPアドレスと範囲を許可したい:

acl payment {
  "1.2.3.4"/28;
  "1.3.3.7";
}

次にvcl_recv、の直前に以下を追加しますreturn (lookup)

if (! req.http.Authorization ~ "Basic XXXXXXXXX"
&& ! client.ip ~ payment
&& ! req.url ~ "^/index.php/ADMIN/.*/upload") {
    error 401 "Restricted";
}

payment上記で定義されたACLです。また、Flashアップローダーは認証ヘッダーを送信しないため、HTTP基本認証の背後で失敗するため、アップロードルートへのアクセスも許可します。ADMINを実際の管理URLに置き換えます。この方法で他の例外を追加できます。

XXXXXXXXXは、base64でエンコードされたユーザー名とパスワードです。この文字列を生成するには、シェルで次を実行します。

$ echo -n "username:password" | base64

次に、VCLの最後にこれを追加して、401エラー応答を定義します。

sub vcl_error {
if (obj.status == 401) {
  set obj.http.Content-Type = "text/html; charset=utf-8";
  set obj.http.WWW-Authenticate = "Basic realm=Secured";
  synthetic {" 

 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" 
 "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">

 <HTML>
 <HEAD>
 <TITLE>Error</TITLE>
 <META HTTP-EQUIV='Content-Type' CONTENT='text/html;'>
 </HEAD>
 <BODY><H1>401 Unauthorized (varnish)</H1></BODY>
 </HTML>
 "};
  return (deliver);
}
}
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.