সীমাবদ্ধ অ্যাক্সেস সহ ম্যাজেন্টো মঞ্চ পরিবেশ স্থাপন করা

Question

আমি কিছু অ্যাক্সেস বিধিনিষেধের সাথে মঞ্চস্থ পরিবেশ স্থাপনের সর্বোত্তম উপায়টি বের করার চেষ্টা করছি।

সহজ সমাধানটি হ'ল বেসিক অথেনটিকেশনটি ছুঁড়ে ফেলা, তবে তারপরে পারফরম্যান্স অপটিমাইজেশন পরীক্ষা করার সময় আমি এটিতে গুগল পেজ স্পিড ইনসাইটগুলি নির্দেশ করতে সক্ষম হবো না, পাশাপাশি অন্যান্য অনুরূপ বাহ্যিক পরিষেবাদি যা আমি এটি অ্যাক্সেস করতে চাই।

এটি অনুসন্ধান ইঞ্জিনগুলিতে প্রদর্শিত হতে বাধা দেওয়ার জন্য এটি রোবট.টেক্সট দ্বারা সম্পূর্ণরূপে প্রকাশ্য করতে পারে। তবে আমার উদ্বেগটি হ'ল যে রোবটস টেক্সটে কোনও ভুল হওয়ার ঝুঁকি মোটামুটি বেশি, এবং আমাকে এ নিয়ে চিন্তিত হওয়ার দরকার নেই।

আপনি যদি সার্চ ইঞ্জিনগুলি অবরুদ্ধ করেন না (বা যদি কেউ এটিকে অবহেলা করেন) তবে আপনি লাইভ গ্রাহকরা আপনার স্টেজিং সাইটে অর্ডার দিচ্ছেন, যা তাদের খুশি করবে না।

বা আরও খারাপ, যদি আপনি ভুলক্রমে রোবটস.টেক্সটকে উত্পাদনে মোতায়েন করেন তবে আপনি আপনার সমস্ত গুগল রস এবং বিক্রয় ভাল পরিমাণে হারাবেন।

সুতরাং যে বিকল্পটি আমি পছন্দ করছি তা হ'ল একটি সাধারণ আইপি ঠিকানার সীমাবদ্ধতা। তবে আমি Nginx পুনরায় আরম্ভ না করেই বিধিনিষেধগুলি যুক্ত / সরিয়ে ফেলতে সক্ষম হতে চাই, পরিবর্তনগুলি করার সময় পুনরায় ঝুঁকি হ্রাস করতে।

সুতরাং আমি একটি দ্রুত মডিউলটির দিকে ঝুঁকতে শুরু করছি যা সক্ষম হয়ে গেলে বিকাশকারী আইপি অ্যাড্রেসগুলিতে সন্ধান করবে এবং ব্যবহারকারীর আইপি ঠিকানা (বা এক্স_ফোরওয়ার্ডED_FOR) এটি মিলে গেলে কেবলমাত্র (সামনের এবং ব্যাকএন্ড) সাইটে অ্যাক্সেসের অনুমতি দেবে।

ভাবছেন যদি এটিকে কোনও যুক্তিসঙ্গত সমাধান বলে মনে হচ্ছে বা এমন সহজ কিছু আছে যা আমি মিস করছি।

আপডেট: এই যে রোবটসটিটিএসটি একটি নেটিভ ব্যাকএন্ড স্যুইচ এর মাধ্যমে নিয়ন্ত্রণ করা যায় এবং ডেমো স্টোর নোটিশটি কোনও বৈধ গ্রাহকের আদেশকে আটকাতে পারে, এবং যেহেতু আমি মঞ্চস্থানে পাবলিক অ্যাক্সেস সম্পর্কে সত্যই উদ্বিগ্ন নই, আমি ফিলের সমাধানটি পছন্দ করি।

তবে যে কেউ তাদের মঞ্চস্থানের সাইটে অ্যাক্সেস সীমাবদ্ধ রাখতে চায় না তাদের জন্য, আমি মনে করি ক্রিসের সমাধান হ'ল উপায়।

আপডেট 2: রোবট.টিএসটি বিকল্পগুলি সিস্টেম কনফিগারেশন> ডিজাইন> এইচটিএমএল হেডে কী করণীয় তা 100% নিশ্চিত নয় তবে আমার ক্ষেত্রে - এবং একটি সংক্ষিপ্ত অনুসন্ধান থেকে এটি সাধারণ বলে মনে হয় - আমার কাছে কেবল একটি ফ্ল্যাট রোবট.টিএসটি আছে যে পাঠ্য ফাইলটি ব্যবহৃত হচ্ছে সেই জায়গায়, যাতে কনফিগার বিকল্পটি সম্মানিত হচ্ছে না।

তাই আমি আপাতত রক্ষণাবেক্ষণের মডিউলটি নিয়ে যাচ্ছি: https://github.com/aleron75/Webग्रीffe_Maintain

Answer 1

কয়েকটি পরামর্শ - কিছু বিল্ট ইন!

- বিকাশকারী আইপি নিষেধাজ্ঞানটি সিস্টেম কনফিগার ইন> বিকাশকারী অন্তর্নির্মিত:

এটি আইপি অ্যাক্সেসকে সীমাবদ্ধ করে না। বরাবর অগ্রসর.

• আইপি সীমাবদ্ধতা শক্ত এবং আমি ব্যক্তিগতভাবে ব্যক্তিগতভাবে ফায়ারওয়ালে এটি পরিচালনা করতে পছন্দ করি। আইপি টেবিলগুলিও একজন প্রার্থী, যেমন এইচটিসেসের সীমাবদ্ধতা বা ইনডেক্স.এফপি মাধ্যমে $_SERVER['REMOTE_ADDR']।

• সিস্টেম কনফিগারেশন> ডিজাইন> এইচটিএমএল হেডে মঞ্চস্থ থাকাকালীন সিএমএসে ডিফল্ট প্রতি পৃষ্ঠার রোবট মেটা আপডেট করুন NOINDEX / NOFOLLOW এ:

• একই কনফিগার অঞ্চলে একটি ডেমো স্টোর বিজ্ঞপ্তি প্রদর্শন করার ক্ষমতা :

Comments

ধন্যবাদ ফিল। আমি এক প্রকারের কথা ভুলে গিয়েছিলাম যে রোবটগুলি একটি ডিফল্ট ব্যাকএন্ড বিকল্প ছিল, আমার ধারণা রোবটসটিটিএসটিএস ফাইলগুলির সাহায্যে ম্যানুয়ালি ঝাঁকুনির চেয়ে কেবল এটি ব্যবহার করা কিছুটা ঝুঁকিপূর্ণ করে তোলে। আমি আসলে বিকাশকারী আইপি নিষেধাজ্ঞাগুলি সম্পর্কে সচেতন ছিলাম, তবে তারা আসলে আপনাকে সাইটে অ্যাক্সেস সীমাবদ্ধ করতে সহায়তা করে না, তাই না? শুধুমাত্র বিকাশকারী বৈশিষ্ট্যগুলিতে? এবং ডেমো নোটিশ - হ্যাঁ যে অবশ্যই গ্রাহকদের ভুল, ভাল কল দিয়ে অর্ডার দেওয়া অবশ্যই এড়ানো উচিত।

— কালেঞ্জর্ডান

খোশ ঠিক বলেছেন। আমি জানি না যে আমি কীভাবে এটি জানি না।

— ফিলিঙ্কল

Answer 2

আমাদের বেশিরভাগ মঞ্চ পরিবেশকে লক ডাউন করার প্রাথমিক উপায়টি হল বেসিক অনুমোদন। তবে আমাদের ইঞ্জিন দ্বারা আবিষ্কার হওয়া থেকে বিরত রাখতে, কোনও পাবলিক ওয়েবসাইটে প্রদর্শিত লিঙ্কটি বাদ দিয়ে (এটি কখনও হয় না), এবং গুগল দ্বারা সূচক হওয়া থেকে রোধ করতে আমাদের প্রতিরোধমূলক ব্যবস্থাও রয়েছে।

আমি /etc/httpd/conf.d/robots.confনিম্নলিখিত উপনামটি দিয়ে একটি বিধি তৈরি করেছি :

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

ওরফে সমস্ত অনুরোধগুলি রোবটস.টেক্সট লোকেশনকে লকডাউন ফাইলটিতে পাঠায়। এর অর্থ দাঁড়ায় যে ম্যাজেন্টো স্টেজিং রুটে রোবটস.টি.এস.টি. ফাইলে যা আছে তা বিবেচ্য নয়, সার্ভার সর্বদা নিম্নলিখিত নিয়মগুলি পরিবেশন করবে:

User-agent: *
Disallow: /

অবস্থান এবং যে কোনওটিকে সন্তুষ্ট করা আমাদের কাছে বিশ্বব্যাপী বিধিবিধি নেই বলেই প্রমাণীকরণ নির্বিশেষে রোবট.এসটিএসটি ফাইলটি যে কারও কাছে পরিবেশন করা যায় disallow from any।

পাসওয়ার্ড প্রমাণীকরণ জন্য, আমি যাতে আমি সাময়িকভাবে যোগ করে একটি একক সাইটে প্রমাণীকরণ খুলতে পারে নিয়ম সেটআপ পেয়েছেন Satisfy anyকরার .htaccessফাইল। এটি কারণ আমরা একই উত্সর্গীকৃত অভ্যন্তরীণ স্টেজিং সার্ভারে একাধিক পর্যায়ের সাইটগুলি পরিচালনা করি। এটি প্রত্যেকের জন্য বজায় রাখার সময় নির্দিষ্ট আইপি ঠিকানাগুলিতে পাসওয়ার্ড প্রমাণীকরণ অপসারণের allow fromপাশাপাশি নিয়মগুলিও সেট করার অনুমতি দেয় Satisfy any(যদি আমার সত্যিই প্রয়োজন হয়)।

আমি বোর্ড জুড়ে আইপি ভিত্তিক শ্বেত তালিকাটি পছন্দ না করার কারণটি (যেমন কোনও পাসওয়ার্ড ভিত্তিক প্রমাণীকরণ নয়) কারণ ক্লায়েন্টের আইপি ঠিকানাগুলি সর্বদা স্থির থাকে না। যার অর্থ আমরা তখন তাদের আইপিগুলি আপডেট করতে হবে তাদের দৈনিক বা সাপ্তাহিক ভিত্তিতে তাদের আইএসপি ডিএইচসিপি লিজটি কতক্ষণ ধরে রাখবে তার উপর নির্ভর করে তাদের অ্যাক্সেস পেতে IP

ডিএনএসের জন্য, আমরা ওয়াইল্ডকার্ড ডিএনএস ব্যবহার করি যাতে ডিএনএস ক্রোলাররা সমস্ত স্টেজ সাইট হোস্টনামে পিকআপ না করে যাতে পাবলিক ডিএনএস থাকা দরকার। গুগল আসলে ডিএনএস রেকর্ড থেকে একটি সাইট বাছাই করবে। এটি এটিকে প্রতিরোধ করে, যার অর্থ এটি তাদের সন্ধান করার একমাত্র উপায় হ'ল যদি কেউ কোনও জায়গায় কোনও লিঙ্ক রেখে যায়। তবে রোবট ফাইলকে একটি নিষেধাজ্ঞার নিয়ম মেনে চলতে বাধ্য করার সাথে যদি তারা কোনও লিঙ্ক খুঁজে পান তবে এটি সূচীকরণ বন্ধ করে দেবে।

আমি যদি কোনও ব্যবসায়ীর প্রতিষ্ঠানের ওয়েবসাইটের জন্য কোনও মঞ্চ সাইট চালাবার জায়গায় থাকি, আমি কিছুটা আলাদাভাবে করতাম এবং পরিচিত আইপি অ্যাড্রেস না আসলে স্টেজ বাক্সে আগত সমস্ত ট্র্যাফিক কেবল অবরুদ্ধ করে ফেলতাম। সাইটে প্রত্যন্তভাবে (ইন-হাউস) কাজ করা যে কোনও ব্যক্তির কাছে স্ট্যাটিক আইপি না থাকলে যা আমি হোয়াইটলিস্ট করতে পারি তা অ্যাক্সেস করার জন্য কোনও কোম্পানির ভিপিএন এর সাথে সংযোগ স্থাপন করতে হবে।

আপনার যদি পেমেন্ট প্রসেসরের ইন্টিগ্রেশনগুলির মতো বিষয়গুলি পরীক্ষা করতে হয় তবে সর্বজনীন গেটওয়েগুলির বিপরীতে, অর্থ প্রদানের প্রক্রিয়াটি অনুসরণ করার জন্য সার্ভারে কলব্যাক করতে হবে।

Comments

এটা সত্যিই চিন্তাশীল। আমরা বুনিয়াদি প্রমাণীকরণ ব্যবহার, যদিও, সময় এটি নাটক মঞ্চস্থ যে আপনি উপরের কল আউট একই চ্যালেঞ্জ উপস্থাপন অধিকাংশ: ইত্যাদি পেমেন্ট processers,

— philwinkle

Answer 3

আমি একটি রক্ষণাবেক্ষণ মোড সক্ষম করার জন্য একটি মডিউল তৈরি করেছি যা ব্যবহারকারীদের ফ্রন্টযুক্ত অ্যাক্সেস করার একই প্রভাবের সাথে ব্যবহার করা যেতে পারে (অ্যাডমিন নয় যা ম্যাজেন্টোর নেটিভ আইপি ব্লকিং বৈশিষ্ট্যের সাথে সীমাবদ্ধ থাকতে পারে)।

আপনি কিছু আইপিগুলিকে রক্ষণাবেক্ষণ মোড সক্ষম থাকলেও সামনের অংশটিতে অ্যাক্সেসের অনুমতি দিতে পারেন।

সম্ভবত আপনি এটি চেষ্টা করতে পারেন আশা করে এটি সহায়তা করতে পারে। এটি নিখরচায় এবং মুক্ত উত্স: https://github.com/aleron75/Web ग्रीffe_Main مينেন্ট

Comments

+1 ভাল! এটি হ'ল একধরণের মডিউল যা আমার মনে ছিল। আপনি বার্নিশের পিছনে এটি পরীক্ষা করেছেন?

— kalenjordan

হাই, দুর্ভাগ্যক্রমে আমি বার্নিশের পিছনে এটি পরীক্ষা করিনি, দুঃখিত। তুমি কি তা করতে? ;-)

— আলেসান্দ্রো রনচি

আমার মঞ্চ পরিবেশে কাজ করা। আমি নিশ্চিত যদি এই যুক্তি খ কাজ করবে / C আমি দেখেছি ছিল না REMOTE_ADDRপাওয়া যাবে কিন্তু সঠিক ঠিকানা না, তাই আমি মনে করি এটা বিরুদ্ধে তুলনা করা যায় পারেন REMOTE_ADDR বা X_FORWARDED_FOR। মঞ্চে সূক্ষ্মভাবে কাজ করা যদিও আমি ব্যক্তিগতভাবে এখনও এটিতে খনন সম্পর্কে খুব বেশি চিন্তিত নই।

— কালেঞ্জর্ডান

Answer 4

এটি করার বিভিন্ন উপায় রয়েছে।

একটি উপায় হ'ল আপনার বিকাশকারীদের সঠিক / আইপি ঠিকানার মাধ্যমে তাদের / হোস্ট ফাইলটি সম্পাদনা করা।

সেখানে একটি এক্সটেনশান রয়েছে যা আরও মার্জিত উপায়ে এটি করার দাবি করেছে: http://www.magentocommerce.com/magento-connect/et-ip-security.html

Comments

ধন্যবাদ ক্রিস! আমি মনে করি আমি এখন ডেমো স্টোরের বৈশিষ্ট্যগুলি ব্যবহার করার দিকে ঝুঁকছি যা আমি এটি সম্পর্কে ভাবছি। যেহেতু আমার কাছে রোবটস টেক্সট সহ ম্যানুয়ালি ঘুরতে হবে না এবং ডেমো স্টোরের বিজ্ঞপ্তি রয়েছে, তাই আমি মনে করি এটি যথেষ্ট। তবে যে কেউ মঞ্চে অ্যাক্সেসকে সীমাবদ্ধ রাখতে চান, আমি মনে করি যে আপনি যে মডিউলটি পেয়েছেন সেটি হ'ল উপায়। ধন্যবাদ !!

— কালেঞ্জর্ডান

Answer 5

যেহেতু আপনি মন্তব্যে বার্নিশ সম্পর্কে জিজ্ঞাসা করেছেন, তাই আমি ব্যতিক্রমগুলি সহ বার্নিশ ব্যবহার করে এইচটিটিপি বেসিক প্রমাণীকরণের সাথে আমার কনফিগারেশনটি ভাগ করতে যাচ্ছি। আপনাকে এটি ভিসিএলে সেট আপ করতে হবে, অন্যথায় ক্যাশেড পৃষ্ঠাগুলি সর্বদা অ্যাক্সেসযোগ্য হবে।

বার্নিশ ভিসিএল কনফিগারেশন

আমি প্রদানের প্রদানকারীর কলব্যাক এবং এর জন্য নির্দিষ্ট আইপি ঠিকানা এবং রেঞ্জগুলির অনুমতি দিতে চাই, যা আমি ভিসিএল ফাইলের শীর্ষে এসিএল হিসাবে সংজ্ঞায়িত করেছি:

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এসিএলটি উপরে বর্ণিত। আমি আপলোডের রুটে অ্যাক্সেসের অনুমতিও দেই কারণ ফ্ল্যাশ আপলোডার প্রমাণীকরণ শিরোনাম প্রেরণ করে না এবং এইভাবে HTTP বেসিক অ্যাথের পিছনে ব্যর্থ হয়। আপনার প্রকৃত অ্যাডমিন URL দিয়ে অ্যাডমিন প্রতিস্থাপন করুন। আপনি অন্য কোনও ব্যতিক্রম এভাবে যুক্ত করতে পারেন।

XXXXXXXXX হল বেস 64 এনকোডেড ব্যবহারকারীর নাম এবং পাসওয়ার্ড। এই স্ট্রিংটি তৈরি করতে শেলটিতে নিম্নলিখিতটি চালান:

$ echo -n "username:password" | base64

তারপরে 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);
}
}