1: शामिल फ़ाइलों की गिनती की जाँच करना
if( count(get_included_files()) == ((version_compare(PHP_VERSION, '5.0.0', '>='))?1:0) )
{
exit('Restricted Access');
}
तर्क: यदि न्यूनतम शामिल गणना पूरी नहीं हुई है, तो पीएचपी बाहर निकलता है। ध्यान दें कि PHP5 से पहले, बेस पेज को शामिल नहीं माना जाता है।
2: वैश्विक स्थिरांक को परिभाषित और सत्यापित करना
// In the base page (directly accessed):
define('_DEFVAR', 1);
// In the include files (where direct access isn't permitted):
defined('_DEFVAR') or exit('Restricted Access');
तर्क: यदि स्थिरांक को परिभाषित नहीं किया जाता है, तो निष्पादन आधार पृष्ठ से शुरू नहीं होता है, और PHP निष्पादन को रोक देगा।
ध्यान दें कि उन्नयन और भविष्य के परिवर्तनों के दौरान पोर्टेबिलिटी के लिए, इस प्रमाणीकरण विधि को मॉड्यूलर बनाने से कोडिंग ओवरहेड में काफी कमी आएगी क्योंकि परिवर्तनों को हर एक फ़ाइल में हार्ड-कोड करने की आवश्यकता नहीं होगी।
// Put the code in a separate file instead, say 'checkdefined.php':
defined('_DEFVAR') or exit('Restricted Access');
// Replace the same code in the include files with:
require_once('checkdefined.php');
इस तरह अतिरिक्त कोड को लॉगिंग और विश्लेषणात्मक उद्देश्यों के लिए जोड़ा जा सकता checkdefined.php है, साथ ही उपयुक्त प्रतिक्रियाएं उत्पन्न करने के लिए भी।
क्रेडिट जहां क्रेडिट देय है: पोर्टेबिलिटी का शानदार विचार इस उत्तर से आया है ।
3: रिमोट एड्रेस प्राधिकरण
// Call the include from the base page(directly accessed):
$includeData = file_get_contents("http://127.0.0.1/component.php?auth=token");
// In the include files (where direct access isn't permitted):
$src = $_SERVER['REMOTE_ADDR']; // Get the source address
$auth = authoriseIP($src); // Authorisation algorithm
if( !$auth ) exit('Restricted Access');
इस पद्धति के साथ दोष को अलग-थलग निष्पादन है, जब तक कि आंतरिक अनुरोध के साथ सत्र-टोकन प्रदान नहीं किया जाता है। किसी एकल सर्वर कॉन्फ़िगरेशन के मामले में लूप-बैक एड्रेस या मल्टी-सर्वर या लोड-संतुलित डेटा इन्फ्रास्ट्रक्चर के लिए व्हाइट-लिस्ट के माध्यम से सत्यापित करें।
4: टोकन प्राधिकरण
पिछली पद्धति के समान, कोई भी GET या POST का उपयोग किसी अधिकृत टोकन को शामिल करने के लिए कर सकता है:
if($key!="serv97602"){header("Location: ".$dart);exit();}
एक बहुत ही गन्दा तरीका, लेकिन एक ही समय में शायद सबसे सुरक्षित और बहुमुखी, जब सही तरीके से उपयोग किया जाता है।
5: वेबसर्वर विशिष्ट कॉन्फ़िगरेशन
अधिकांश सर्वर आपको व्यक्तिगत फ़ाइलों या निर्देशिकाओं के लिए अनुमति प्रदान करने की अनुमति देते हैं। आप अपने सभी प्रतिबंधित निर्देशिकाओं में शामिल कर सकते हैं, और उन्हें अस्वीकार करने के लिए सर्वर को कॉन्फ़िगर किया गया है।
APACHE में उदाहरण के लिए, कॉन्फ़िगरेशन .htaccessफ़ाइल में संग्रहीत है । यहाँ ट्यूटोरियल ।
ध्यान दें कि सर्वर-विशिष्ट कॉन्फ़िगरेशन मेरे द्वारा अनुशंसित नहीं हैं क्योंकि वे विभिन्न वेब-सर्वरों में पोर्टेबिलिटी के लिए खराब हैं। सामग्री प्रबंधन प्रणालियों जैसे मामलों में जहां इनकार-एल्गोरिथ्म जटिल है या इनकार की गई निर्देशिकाओं की सूची बड़ी है, यह केवल भीषण सत्रों को भीषण बना सकता है। अंत में इसे कोड में संभालना सबसे अच्छा है।
6: प्लेसिंग में साइट के रूट में एक सुरक्षित निर्देशिका OUTSIDE शामिल है
सर्वर वातावरण में पहुंच सीमाओं के कारण कम से कम पसंद किया जाता है, लेकिन यदि आप फ़ाइल-सिस्टम तक पहुंच रखते हैं, तो यह एक शक्तिशाली तरीका है।
//Your secure dir path based on server file-system
$secure_dir=dirname($_SERVER['DOCUMENT_ROOT']).DIRECTORY_SEPARATOR."secure".DIRECTORY_SEPARATOR;
include($secure_dir."securepage.php");
तर्क:
- उपयोगकर्ता
htdocsफ़ोल्डर के बाहर किसी भी फाइल का अनुरोध नहीं कर सकता क्योंकि लिंक वेबसाइट के पते सिस्टम के दायरे से बाहर होंगे।
- Php सर्वर फ़ाइल-सिस्टम को मूल रूप से एक्सेस करता है, और इसलिए कंप्यूटर पर फ़ाइलों को उसी तरह एक्सेस कर सकता है, जैसे आवश्यक विशेषाधिकार वाला सामान्य प्रोग्राम कैसे कर सकता है।
- इस निर्देशिका में शामिल फ़ाइलों को रखकर, आप यह सुनिश्चित कर सकते हैं कि php सर्वर उन्हें एक्सेस करने के लिए मिलता है, जबकि हॉटलिंकिंग उपयोगकर्ता से वंचित है।
- यहां तक कि अगर वेबसर्वर के फाइल सिस्टम एक्सेस कॉन्फ़िगरेशन ठीक से नहीं किया गया था, तो यह विधि उन फाइलों को गलती से सार्वजनिक होने से रोक देगी।
कृपया मेरे अपरंपरागत कोडिंग सम्मेलनों का बहाना करें। किसी भी प्रतिक्रिया की सराहना की है।