Habré पर
कई लेख पहले से ही प्रतिबंधित साइटों की सूची तक पहुँचने, इसके अद्यतन और उपयोग के साथ संबंधित कठिनाइयों के बारे में थे। यह लेख पहले दूसरों द्वारा व्यक्त की गई टिप्पणियों (टिप्पणियों सहित) की एक तार्किक निरंतरता है। तुरंत एक आरक्षण करें कि मैं किसी प्रदाता का कर्मचारी नहीं हूं।
तो, मान लीजिए कि आप इंटरनेट एक्सेस सेवाओं के साथ ग्राहकों को प्रदान करने जा रहे हैं, या, बस, प्रदाता बन गए हैं। ग्राहक वफादारी हासिल करने के लिए, आपने एक फैंसी डीपीआई-सिस्टम खरीदने का फैसला किया, यूआरएल द्वारा निषिद्ध जानकारी को अवरुद्ध किया और कुछ भी अतिरंजित नहीं किया। केवल URL द्वारा डोमेन या IP द्वारा कोई फ़िल्टरिंग नहीं! सभी कानूनी, नौकरशाही, नैतिक और मौद्रिक मुद्दे सुलझे हुए हैं, तकनीकी मुद्दे बने हुए हैं। यह प्रतिबंधित साइटों की सूची का एक तैयार-निर्मित स्वचालित डाउनलोड लेने के लिए ही बना हुआ है और इस सूची के डीपीआई-सिस्टम में स्वचालित लोडिंग को उस प्रारूप में कॉन्फ़िगर करता है जिसे वह समझता है। यानी एक स्क्रिप्ट कनवर्टर लिखें। इसलिए, मुझे आपको निराश करना होगा - एक कार्यशील कनवर्टर लिखने से काम नहीं चलेगा। यह तब तक काम नहीं करेगा जब तक कि रोसकोम्नाडज़ोर स्थानांतरित नहीं होता है और डेटा प्रारूप को बदलता है, और मौजूदा सूची आइटमों में स्पष्ट त्रुटियों को भी ठीक करता है।
शुरू करने के लिए, किस प्रारूप में रोजकोमनादज़ोर निषिद्ध सूचना की सूची देता है। यह एक्सएमएल
वाहक के लिए
मेमो के हिस्से के रूप में प्रकाशित एक एक्सएसडी स्कीमा के अनुरूप है। या, अधिक बस, एक XML, जिसमें निम्न जैसे ब्लॉक का अनुक्रम होता है:
<content id="105" includeTime="2012-11-11T15:39:37"> <decision date="2012-11-04" number="2/1/16402" org=""/> <url>http://go-****.com/workshop/</url> <domain>go-****.com</domain> <ip>62.75.***.***</ip> </content>
उसी समय, योजना के अनुसार, <url> टैग शून्य से अनंत तक हो सकते हैं, उसके बाद शून्य या एक <डोमेन> टैग, और फिर एक से अनंत तक <ip> टैग। हम स्पष्ट रूप से <url> टैग में रुचि रखते हैं। तो, ऐसा लगता है, आपको बस URL की सूचीबद्ध सूची तक पहुंच को अवरुद्ध करना होगा।
और अब देखते हैं कि किस तरह के कार्यों को पहले हल किया गया था और किस स्मार्ट शब्दों के बारे में बात की गई थी।
सर्वरों पर यूआरएल तक पहुंच न केवल लोगों से, बल्कि रोबोट से भी बंद होनी चाहिए। ऐसा करने के लिए,
दस्तावेज़ित सिंटैक्स के साथ /robots.txt फ़ाइल का उपयोग करें। समान रूप से महत्वपूर्ण,
शब्दार्थ एक ही दस्तावेज़ में विस्तार से वर्णित हैं, अर्थात्। रोबोट किसी भी URL पर जा सकता है या नहीं, इस मुद्दे को हल करने के लिए प्रत्येक प्रविष्टि की व्याख्या के लिए सटीक नियम:
मिलान प्रक्रिया हर ओकटेट की तुलना पथ के हिस्से में करती है
URL और रिकॉर्ड से पथ। यदि% xx एन्कोडेड ऑक्टेट है
सामना करना पड़ा है जब तक कि यह तुलना से पहले unencoded है, जब तक कि यह नहीं है
"/" चरित्र, जिसका एक मार्ग में विशेष अर्थ है। द मैच
सकारात्मक रूप से मूल्यांकन करता है अगर और केवल अगर रास्ते से अंत
ऑक्टेट्स में अंतर सामने आने से पहले रिकॉर्ड तक पहुंचा जाता है।
यही है, काम करने के लिए प्रविष्टि के लिए, robots.txt प्रविष्टि
का पथ URL में पथ
उपसर्ग होना चाहिए। Roskomnadzor वेबसाइट पर बस कोई समान नियम नहीं हैं, और यह, मेरे दृष्टिकोण से, एक बग है। शायद उनके लिए ये नियम लिखने की कोशिश करें? और आखिरकार, ऐसा लगता है कि उपसर्ग द्वारा फ़िल्टरिंग, और सटीक URL मिलान द्वारा नहीं, लोगों से सामग्री अवरुद्ध करने के मामले में अधिक उपयुक्त है। Roskomnadzor साइट के सभी URL को सूचीबद्ध नहीं करेगा, जिसे पूरी तरह से ब्लॉक किया जाना चाहिए!
Robots.txt मानक में
क्लीन-परम एक्सटेंशन भी है। यह इंगित करता है कि कौन से
जीईटी पैरामीटर महत्वहीन हैं , अर्थात्। URL की तुलना करते समय विचार नहीं किया जाना चाहिए। मापदंडों के महत्व की बहुत अवधारणा महत्वपूर्ण है - यह खराब है अगर उपयोगकर्ता URL में अनब्लॉक_मे = 1 और प्रश्न चिह्न के बाद लॉक को बायपास कर सकता है। केवल लोगों से सामग्री को अवरुद्ध करने के मामले में, महत्वपूर्ण मापदंडों के बारे में बात करना अधिक सही होगा और यह कि इन मापदंडों का क्रम वास्तव में मायने नहीं रखता है।
कुल मिलाकर, इस तरह की सट्टा योजना प्रतिबंधित साइटों की रजिस्ट्री में URL के अर्थ की एक ठोस व्याख्या के रूप में उभरती है:
- निम्न चरणों को लागू करने से पहले, रजिस्ट्री में URL और उपयोगकर्ता द्वारा एक्सेस किए गए URL को "/" वर्ण के अपवाद के साथ डीकोड ओकटेट के साथ% xx प्रारूप में एन्कोड किए गए ओकटेट्स को बदलकर सामान्य किया जाना चाहिए।
- यदि URL में प्रतिबंधित साइट की सूची में "?" चिह्न नहीं है, तो काम करने के लिए अवरुद्ध करने के लिए, रजिस्ट्री में URL उस URL का उपसर्ग होना चाहिए, जिसे उपयोगकर्ता ने एक्सेस किया था।
- यदि URL में प्रतीक है ""? प्रतिबंधित साइटों की सूची में है, तो काम करने के लिए अवरुद्ध करने के लिए, रजिस्ट्री में URL और उपयोगकर्ता द्वारा एक्सेस किया गया URL पहले चरित्र तक के पदों में चरित्र द्वारा संयोग होना चाहिए? " समावेशी। रजिस्ट्री से URL में GET मापदंडों का सेट उपयोगकर्ता URL से GET मापदंडों के सेट का सबसेट होना चाहिए। GET पैरामीटर को "&" वर्ण द्वारा अलग करने के लिए माना जाता है।
केवल यह योजना अभी भी अधूरी है। क्या केस-संवेदी तुलना आवश्यक है? वास्तव में मामला कितना संवेदनशील है? आखिरकार, हमारे पास केवल एक अज्ञात एन्कोडिंग में बाइट्स हैं?
और सबसे महत्वपूर्ण बात, रजिस्ट्री में मौजूदा डेटा इस योजना के लायक नहीं है। ये रिकॉर्ड क्या हैं:
<url>http://*******tube.ru/index.php</url> <url>http://********.kiev.ua/index.php</url> <url>http://***forum.org/index.php?s=3a95f6da301a36067be68329be6f88a8&showforum=8</url> <url>http://****lib.net/b/27415/read#t16</url>
पहले दो मामलों में, मेरे लिए, विचारों के एक पाठक के रूप में, पूरी साइट को ब्लॉक करने का इरादा स्पष्ट है, इसके बजाय केवल URL अवरुद्ध हैं, जिनमें से पथ /index.php से शुरू होता है। तीसरे में, एस पैरामीटर एक तुच्छ सत्र पहचानकर्ता के समान है। चौथे में आमतौर पर हैश टैग होता है। सामान्य तौर पर, सर्किट के काम करने के लिए स्रोत डेटा बहुत गंदा है।
और अगर यह काम करता है, तो भी मैं इस योजना का उपयोग नहीं करूंगा। जब मैंने इसे लिखा था, तो मैंने
कुछ अनुमान लगाने के बहुत
प्रयास किए , और यह सब दृढ़ता से एक और
लिबास्रल क्लोन लिखने के प्रयास जैसा दिखता है। कानूनों की व्याख्या करते समय, ऐसे कार्य अस्वीकार्य हैं।
इसलिए, अगर कोई आपको zapret-info.gov.ru के आधिकारिक डेटा के आधार पर URL फ़िल्टरिंग सिस्टम बेचने की कोशिश कर रहा है, तो उसे विश्वास न करें - यह निश्चित रूप से तलाक है। जब तक Roskomnadzor अपना डेटा सही मायने में मशीन-पठनीय और स्पष्ट रूप से व्याख्या नहीं करता है, तब तक ऐसे समाधान बस काम नहीं कर सकते हैं। आज तक, रजिस्ट्री के XML डंप में <url> टैग केवल रजिस्ट्री में साइट को शामिल करने की वैधता को सत्यापित करने के लिए संदर्भ जानकारी के रूप में उपयुक्त है। जो हमें वास्तव में चाहिए वह URL नहीं है, बल्कि नियमों को फ़िल्टर करना है।
अब इस बारे में बात करते हैं कि जब लोग अपनी सूचियों द्वारा URL फ़िल्टर करने की मूलभूत संभावना के बारे में बात करते हैं तो Roskomnadzor क्या कर सकता है, लेकिन वास्तव में ऐसी कोई संभावना नहीं है।
सबसे आसान (और, मेरी राय में, सबसे सही) तरीका यह है कि इसे छोड़ दें, लेकिन सार्वजनिक रूप से स्वीकार करते हैं कि प्रतिबंधित साइटों की रजिस्ट्री में जानकारी अनुपयुक्त है और URL द्वारा फ़िल्टर करने के लिए उपयुक्त नहीं है। <Url> टैग को छोड़ दें - जैसा कि पहले ही उल्लेख किया गया है, यह लॉक निर्णयों को सत्यापित करने और इस तरह प्रक्रिया की पारदर्शिता सुनिश्चित करने के लिए उपयोगी है।
अधिक जटिल तरीका <url> टैग की सामग्री की व्याख्या करने के लिए नियम लिखना है (जैसा कि मैंने ऊपर करने की कोशिश की) और उनके लिए डेटाबेस की मौजूदा सामग्री को समायोजित करें।
एक अन्य तरीका XML संरचना को फिर से बनाना है। एकल <url> टैग बनाने के बजाय, एक ऐसा निर्माण बनाएं जो उपसर्ग, आवश्यक पैरामीटर और संभवतः अन्य जानकारी संग्रहीत कर सकता है जो संबंधित URL के समूह का वर्णन कर सकता है। फिर इसे
SQUID में "acl aclname url_regex" के लिए या
सिस्को NBAR में "मैच प्रोटोकॉल http url" के लिए ग्लोब में एक नियमित अभिव्यक्ति में बदल दिया जा सकता है।
और इसलिए मुझे लगता है कि पहला तरीका सबसे सही है। ऐसा लगता है कि Roskomnadzor ने इस तरह की कार्य योजना को लागू किया है: एक शिकायत अवैध सामग्री के URL के साथ आती है, मध्यस्थ इसकी जांच करते हैं और डेटाबेस में एक ही URL जोड़ते हैं। शिकायत करने वाले URL को मशीन से पढ़ने योग्य फ़िल्टरिंग नियमों में परिवर्तित करने के लिए इस प्रक्रिया में कोई जगह नहीं है। और यदि आप इसे (अनिवार्य रूप से मैनुअल) कदम बनाने की कोशिश करते हैं, तो आपको उन लोगों की तलाश करने की जरूरत है जो इसे बाहर ले जा सकते हैं। कलाकारों को यही समझाया जाना चाहिए कि मशीन दिमाग नहीं पढ़ सकती। यह उन लोगों को खोजने के लिए भी आवश्यक है जो मनोवैज्ञानिक रूप से स्थिर हैं और खुद को मशीन की जगह पर रखने में सक्षम हैं और जांचते हैं कि क्या नियम वास्तव में उसी तरह काम करता है जैसा कि इसे करना चाहिए। कार्मिक विभाग के लिए एक मुश्किल काम! ठीक है, अगर आप <url> टैग को पूरी तरह से सूचनात्मक रूप से छोड़ देते हैं और स्पष्ट रूप से ऐसा कहते हैं, तो प्रदाताओं को एक फैंसी डीपीआई-सिस्टम पर पैसा खर्च करने की इच्छा नहीं होगी, जो वास्तव में अभी भी अपने इच्छित उद्देश्य के लिए उपयोग नहीं किया जा सकता है।