प्रतिबंधित पहुँच के साथ Magento मंचन पर्यावरण की स्थापना

Question

मैं कुछ एक्सेस प्रतिबंधों के साथ एक मचान वातावरण को सेटअप करने का सबसे अच्छा तरीका जानने की कोशिश कर रहा हूं।

इसका सरल उपाय यह होगा कि बेसिक ऑथेंटिकेशन को फेंक दिया जाए, लेकिन तब मैं प्रदर्शन अनुकूलन का परीक्षण करने के साथ-साथ अन्य समान बाहरी सेवाओं को भी एक्सेस करना चाहता हूं, जिस पर मैं इसे एक्सेस करना चाहता हूं।

इसे खोज इंजन में दिखाने से रोकने के लिए robots.txt के साथ इसे पूरी तरह से सार्वजनिक किया जा सकता है। लेकिन मेरी चिंता यह है कि robots.txt में किसी भी गलती का जोखिम काफी अधिक है, और मुझे इसके बारे में चिंता करने की ज़रूरत नहीं है।

यदि आप खोज इंजन को ब्लॉक नहीं करते हैं (या यदि कुछ इसे अनदेखा करते हैं), तो आप लाइव ग्राहकों को अपनी स्टेजिंग साइट पर ऑर्डर दे रहे होंगे, जो उन्हें खुश नहीं करेगा।

या इससे भी बदतर, यदि आप गलती से robots.txt को उत्पादन में तैनात करते हैं, तो आप अपने सभी Google रस और बिक्री का एक अच्छा हिस्सा खो देंगे।

तो जो विकल्प मुझे पसंद आ रहा है वह एक साधारण आईपी एड्रेस प्रतिबंध है। लेकिन मैं Nginx को पुनरारंभ किए बिना प्रतिबंधों को जोड़ने / हटाने में सक्षम होना पसंद करूंगा, बस बदलाव करते समय जोखिम को फिर से कम करना होगा।

इसलिए मैं एक त्वरित मॉड्यूल की ओर झुकना शुरू कर रहा हूं, जो सक्षम होने पर, डेवलपर आईपी पते को देखेगा और केवल साइट (फ्रंट और बैकएंड) तक पहुंच की अनुमति देगा यदि उपयोगकर्ता का आईपी पता (या X_FORWARDED_FOR) इससे मेल खाता है।

आश्चर्य है कि अगर यह एक उचित समाधान की तरह लगता है या अगर कुछ सरल है जो मुझे याद आ रहा है।

अद्यतन: यह देखते हुए कि robots.txt को एक देशी बैकएंड स्विच के माध्यम से नियंत्रित किया जा सकता है और डेमो स्टोर नोटिस किसी भी वैध ग्राहक के आदेशों को रोक देगा, और चूंकि मैं वास्तव में स्टेजिंग साइट पर सार्वजनिक पहुंच के बारे में चिंतित नहीं हूं, मुझे फिल का समाधान पसंद है।

लेकिन जो कोई भी उनके मंचन स्थल तक पहुंच को प्रतिबंधित करना चाहता है, मुझे लगता है कि क्रिस का समाधान जाने का रास्ता है।

अद्यतन 2: 100% निश्चित नहीं है कि System.t> डिज़ाइन> एचटीएमएल हेड में robots.txt विकल्प क्या करने वाले हैं, लेकिन मेरे मामले में - और एक संक्षिप्त खोज से यह सामान्य प्रतीत होता है - मेरे पास एक सपाट robots.txt है उस स्थान पर पाठ फ़ाइल का उपयोग किया जा रहा है, जिससे कि विन्यास विकल्प का सम्मान नहीं किया जा रहा है।

तो मैं अब के लिए रखरखाव मॉड्यूल के साथ जा रहा हूँ: https://github.com/aleron75/Webgriffe_Maintain

Answer 1

कुछ सुझाव - कुछ अंतर्निहित हैं!

- डेवलपर आईपी प्रतिबंध सिस्टम कॉन्फ़िगरेशन में बनाया गया है> डेवलपर:

यह IP पहुँच को प्रतिबंधित नहीं करता है। के साथ कदम।

• आईपी ​​प्रतिबंध कठिन है और मैं व्यक्तिगत रूप से फ़ायरवॉल पर इसे संभालना पसंद करता हूं। आईपी ​​टेबल भी एक उम्मीदवार है, जैसा कि htaccess प्रतिबंध या $_SERVER['REMOTE_ADDR']index.php के माध्यम से है।

• सिस्टम कॉन्फ़िगरेशन> डिज़ाइन> HTML हेड में मंचन करते समय CMS NOINDEX / NOFOLLOW में डिफ़ॉल्ट प्रति पृष्ठ रोबोट मेटा अपडेट करें।

• समान कॉन्फ़िगरेशन क्षेत्र में, डेमो स्टोर नोटिस प्रदर्शित करने की क्षमता है :

Comments

धन्यवाद फिल। मैं भूल गया था कि रोबोट एक डिफ़ॉल्ट बैकएंड विकल्प था, मुझे लगता है कि यह थोड़ा कम जोखिम भरा है जो कि केवल उपयोग करने के बजाय रोबोटों के साथ मैन्युअल रूप से फ़्यूज़ करने के बजाय। मुझे वास्तव में डेवलपर आईपी प्रतिबंधों के बारे में पता था, लेकिन वे वास्तव में साइट तक पहुंच को प्रतिबंधित करने में आपकी मदद नहीं करते हैं, है ना? केवल डेवलपर सुविधाओं के लिए? और डेमो नोटिस - हां, जो निश्चित रूप से गलती से कॉल रखने वाले ग्राहकों से बचना चाहिए, अच्छी कॉल।

— कालेंजर्डन

गोश आप सही कह रहे हैं। मुझे नहीं पता कि मुझे कैसे पता नहीं था।

— दर्शन करें

Answer 2

हमारे (सबसे) मंचन वातावरण को बंद करने का प्राथमिक साधन बुनियादी प्रमाणीकरण है। लेकिन हमारे पास इंजनों द्वारा खोजे जाने से रोकने के लिए निवारक उपाय भी हैं, एक लिंक को सार्वजनिक वेबसाइट पर दिखाने पर रोक (यह कभी नहीं होता है), और उन्हें 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नियम नहीं होते हैं, तो प्रमाणीकरण की परवाह किए बिना किसी भी तक रोबोट्स.टैक्स फ़ाइल की सेवा की जा सकती है।

पासवर्ड प्रमाणीकरण के लिए, मैं इतना है कि मैं अस्थायी रूप से जोड़कर एक ही साइट पर प्रमाणीकरण खोल सकते हैं नियम सेटअप मिल गया है Satisfy anyकरने के लिए .htaccessफ़ाइल। ऐसा इसलिए है क्योंकि हम एक ही समर्पित आंतरिक स्टेजिंग सर्वर पर कई चरण साइट चलाते हैं। यह सभी के लिए इसे बनाए रखते हुए विशिष्ट IP पतों पर पासवर्ड प्रमाणीकरण को हटाने allow fromके साथ-साथ नियम स्थापित करने की भी अनुमति देगा Satisfy any(यदि मुझे वास्तव में आवश्यकता है)।

कारण यह है कि मुझे पूरे बोर्ड में आईपी आधारित श्वेतसूची पसंद नहीं है (अर्थात बिना पासवर्ड आधारित प्रमाणीकरण) क्योंकि ग्राहक के आईपी पते हमेशा स्थिर नहीं होते हैं। इसका मतलब है कि तब हमें उनके आईपीएस को अपडेट करना होगा ताकि वे अपने आईएसपी डीएचसीपी के पास कितने समय के लिए दैनिक या साप्ताहिक आधार पर पहुंच सकें।

डीएनएस के लिए, हम वाइल्डकार्ड डीएनएस का उपयोग करते हैं ताकि डीएनएस क्रॉलर उन सभी स्टेज साइट होस्टनाम पर पिकअप न करें जिनके लिए सार्वजनिक डीएनएस होना आवश्यक है। Google वास्तव में DNS रिकॉर्ड से एक साइट उठाएगा। यह रोकता है, जिसका अर्थ है कि उन्हें खोजने का एकमात्र तरीका यह है कि कोई व्यक्ति किसी लिंक को कहीं छोड़ता है। लेकिन रोबोट फाइल को एक अस्वीकृत नियम की सेवा के लिए मजबूर करने के साथ अगर वे एक लिंक पाते हैं तो वे इसे अनुक्रमित करना बंद कर देंगे।

क्या मैं कंपनी की वेबसाइट के लिए एक मंच साइट चलाने वाले व्यापारी की जगह पर था, मैं चीजों को थोड़ा अलग तरीके से करूंगा और मंच के बॉक्स पर आने वाले सभी ट्रैफ़िक को सीधे ब्लॉक कर दूंगा जब तक कि इसे आईपी पते नहीं मिलते। साइट पर दूरस्थ रूप से काम करने वाले (इन-हाउस) काम करने वाले किसी व्यक्ति को एक्सेस करने के लिए किसी कंपनी वीपीएन से जुड़ना आवश्यक होगा, यदि उनके पास एक स्टैटिक आईपी नहीं है जिसे मैं श्वेतसूची में दे सकता हूं।

सार्वजनिक DNS होना एक आवश्यक है यदि आपको भुगतान प्रोसेसर एकीकरण जैसी चीजों का परीक्षण करने की आवश्यकता है, जो कि अधिकांश गेटवे के विपरीत, भुगतान प्रक्रिया से गुजरने के लिए सर्वर पर कॉलबैक करना होगा।

Comments

यह वास्तव में विचारशील है। हालांकि, हम बेसिक कॉन्ट्रैक्ट का उपयोग करते हैं, हालांकि, अधिकांश समय यह एक ही चुनौती पेश करता है कि आप ऊपर बताए गए हैं: भुगतान

— प्रोसेसर्स

Answer 3

मैंने एक रखरखाव मोड को सक्षम करने के लिए एक मॉड्यूल विकसित किया है जिसका उपयोग उपयोगकर्ताओं को सामने वाले को अवरुद्ध करने के समान प्रभाव के साथ किया जा सकता है (व्यवस्थापक नहीं जो मैगेंटो के मूल आईपी ब्लॉकिंग सुविधा के साथ सीमित हो सकता है)।

आप कुछ IPs को रखरखाव मोड सक्षम होने के साथ भी फ्रंटएंड तक पहुंचने की अनुमति दे सकते हैं।

शायद आप इसे एक कोशिश दे सकते हैं, उम्मीद है कि यह मदद कर सकता है। यह मुफ़्त और खुला स्रोत है: https://github.com/aleron75/Webgriffe_Maintain

Comments

+1 नाइस! यह ठीक उसी तरह का मॉड्यूल है जो मेरे दिमाग में था। क्या आपने वार्निश के पीछे इसका परीक्षण किया है?

— कालेंजर्डन

नमस्ते, दुर्भाग्य से मैं इसे वार्निश के पीछे परीक्षण नहीं किया, माफ करना। आप ऐसा करेंगे? ;-)

— एलेसेंड्रो रोंची

मेरे मंचन के माहौल में काम करना। मुझे यकीन नहीं था कि यह तर्क काम करेगा b / c मैंने REMOTE_ADDRउपलब्ध होना देखा है, लेकिन सही पता नहीं है, इसलिए मुझे लगता है कि या तो तुलना करना बेहतर हो सकता है । मंचन में ठीक काम कर रहा है, लेकिन मैं अभी तक इसे खुद में खोदने के बारे में चिंतित नहीं हूँ व्यक्तिगत रूप से अभी तक। REMOTE_ADDRX_FORWARDED_FOR

— कालेंजर्दन

Answer 4

ऐसा करने के कई अलग-अलग तरीके हैं।

एक तरीका यह होगा कि आप अपने डेवलपर्स को सही आईपी एड्रेस के साथ अपनी / होस्ट फ़ाइल संपादित करें।

वहाँ एक विस्तार है जो इसे और अधिक सुरुचिपूर्ण तरीके से करने का दावा करता है: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Comments

धन्यवाद क्रिश! मुझे लगता है कि मैं अभी डेमो स्टोर सुविधाओं का उपयोग करने की दिशा में झुकाव कर रहा हूं जो कि मैं इसके बारे में सोचता हूं। चूंकि मुझे robots.txt के साथ मैन्युअल रूप से घूमना नहीं है, और डेमो स्टोर नोटिस है, मुझे लगता है कि यह पर्याप्त है। लेकिन जो कोई भी मचान तक पहुंच को प्रतिबंधित करना चाहता है, मुझे लगता है कि आपके द्वारा पाया गया मॉड्यूल जाने का रास्ता है। धन्यवाद!!

— कालेंजर्डन

Answer 5

चूंकि आपने टिप्पणियों में वार्निश के बारे में पूछा था, इसलिए मैं अपवादों सहित, वार्निश का उपयोग करके HTTP बेसिक ऑथेंटिकेशन के साथ अपने कॉन्फ़िगरेशन को साझा करने जा रहा हूं। आपको इसे वीसीएल में स्थापित करना होगा, अन्यथा कैश्ड पृष्ठ हमेशा सुलभ रहेंगे।

वार्निश VCL कॉन्फ़िगरेशन

मैं भुगतान प्रदाताओं के कॉलबैक के लिए कुछ आईपी पते और पर्वतमाला की अनुमति देना चाहता हूं और इस तरह, जिसे मैं वीसीएल फ़ाइल के शीर्ष पर एसीएल के रूप में परिभाषित करता हूं:

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 है। मैं अपलोड मार्ग तक पहुंचने की अनुमति भी देता हूं क्योंकि फ़्लैश अपलोडर प्रमाणीकरण हेडर नहीं भेजता है और इस तरह HTTP बेसिक ऑथेंटिकेशन के पीछे विफल रहता है। ADMIN को अपने वास्तविक व्यवस्थापक URL से बदलें। आप इस तरह से कोई अन्य अपवाद जोड़ सकते हैं।

XXXXXXXXX बेस 64 एनकोडेड यूज़रनेम और पासवर्ड है। इस स्ट्रिंग को जेनरेट करने के लिए शेल पर निम्नलिखित रन करें:

$ echo -n "username:password" | base64

फिर 401 त्रुटि प्रतिक्रिया को परिभाषित करने के लिए VCL के अंत में इसे जोड़ें:

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);
}
}