और फिर, कैप्चा या नगनेक्स भी जानता है कि कैसे कढ़ाई करना है

परिचय

मैं यहां हेरा गया और कैप्चा के बारे में एक अप्रकाशित लेख ड्राफ्ट में पाया, मैं इसे औपचारिक रूप देना और प्रकाशित करना चाहता था, लेकिन इस्तेमाल किए गए तंत्र और उपकरणों को थोड़ा बदलकर एक नया लेख लिखने का फैसला किया। मेरी राय में यह एक पुराने लेख को पढ़ने के लिए उपयोगी होगा, यह बदतर नहीं होगा।

एक नया लेख लिखने का मुख्य लक्ष्य यह भी नहीं है कि काम के एक अन्य तंत्र को दिखाया जाए, नग्नेक्स की क्षमताओं को दिखाने के लिए कितना है जो कभी-कभी पूरी तरह से भूल जाते हैं, इसे एक प्रतिफल प्रॉक्सी सर्वर मानते हैं।

स्थिति

फ़ाइलों को डाउनलोड करने से बॉट्स को रोकने के लिए, एक परीक्षण "कैप्चा" का उपयोग किया जाता है।

फ़ाइल जंप के लिए फॉर्म बनाते समय, एक कोड और कुछ विकृतियों के साथ एक छवि अपनी स्वचालित पहचान को जटिल करने के लिए बनाई जाती है। सत्यापन के लिए एक कुंजी + कोड जोड़ी को ठीक करने के लिए भंडारण भी है।

फ़ाइल डाउनलोड करने के लिए फ़ॉर्म की पुष्टि करने और कोड के पत्राचार के लिए कैप्चा की जाँच करने पर, फ़ाइल उपयोगकर्ता को दी जाती है या फ़ाइल के लिए एक अद्वितीय लिंक लिंक उत्पन्न होता है। लिंक की विशिष्टता को बैकएंड द्वारा भी नियंत्रित किया जाता है। इसके पुन: उपयोग को रोकने के लिए कुंजी + कोड जोड़ी को भी हटा दिया जाता है।

एक प्रॉक्सी है जो बैकएंड के सभी अनुरोधों को रीडायरेक्ट करती है।

समस्याओं

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

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

निर्णय

कार्यक्षमता का चयन करें

दरअसल, कैप्चा में एक छवि और एक निश्चित कुंजी होती है, जो बैकएंड पर संग्रहीत छवि में कोड से मेल खाती है। छवि बहुत बड़ी नहीं है, और हम इसे बेस 64 में अनुवाद करते हैं और या तो एक टुकड़ा देते हैं:

<img src="data:image/png;base64,{{ IMAGE CODE BASE64 }}"> <input type="hidden" name="key" value="{{ KEY }}"> 

या JSON:

 { ... "data": { "image": "data:image/png;base64,{{ IMAGE CODE BASE64 }}", "key": "{{ KEY }}" } } 

यदि हमारे पास फ़ॉर्म का एक टुकड़ा है, तो हम इसे पेज के मुख्य भाग में सम्मिलित करने के लिए SSI का उपयोग कर सकते हैं, इसके लिए हम प्रॉक्सी पर nginx कॉन्फ़िगरेशन में संबंधित मोड को सक्षम करते हैं:

 ssi on; 

और हमारे द्वारा डाले गए फॉर्म पेज के कोड में:

 ... <form action="download" method="get" ...> ... <!--#include virtual="/x/captcha/generate"--> ... </form> ... 

इस प्रकार, हमने कैप्चा को अलग स्थान या विधियों में मैप करने की कार्यक्षमता आवंटित की है। अब आप कैशिंग कर सकते हैं।

हां, सर्वर साइड शामिल (SSI) तंत्र लगभग भूल गया है, लेकिन इसके लिए nginx मॉड्यूल सभी जीवित लोगों की तुलना में जीवंत है और बहुत जल्दी काम करता है। और वैसे, अगर प्रॉक्सी_पास_ कैश पूरे पृष्ठ को कैश करता है , तो वर्चुअल को शामिल करने का परिणाम कैश नहीं किया जाएगा, लेकिन यह अनुरोध किए जाने पर हर बार निष्पादित किया जाएगा। यह आपको इन्सर्ट को गतिशील बनाने की अनुमति देता है।

कैप्चा कैप्चा

कैशिंग को लागू करने के लिए, हमें विकल्पों की संख्या के आधार पर कुछ यादृच्छिक और नियंत्रित करने की आवश्यकता है, $ request_id चर इस भूमिका के लिए उपयुक्त है - यह काफी यादृच्छिक और हेक्साडेसिमल है, अर्थात्, इस चर का एक निश्चित भाग चुनकर, आप कैश तत्वों की संख्या 16 ^ n तक सीमित कर सकते हैं, जहां n - चर से हमें लेने वाले वर्णों की संख्या। तो:

कैश ज़ोन का निर्धारण करें:

 proxy_cache_path /cache/nginx/captcha levels=1:1 keys_zone=captcha:10m max_size=128m; 

यह निर्धारित करना महत्वपूर्ण है कि हम क्रमशः n का क्या मूल्य चुनते हैं, पैरामीटर इस पर निर्भर करते हैं:

• स्तर = 1: 2
• max_size = 128 मी
• की_ज़ोन = कैप्चा: 10 मी

तो यह सब कुछ के लिए पर्याप्त था, लेकिन कुछ भी नहीं था। अगला, हम कैश कुंजी निर्धारित करते हैं:

 server { ... set $captcha_salt 'salt'; if ( $request_id ~* "(\w{4})$" ) { set $cache_key $1; } ... 

$ Captcha_salt चर अभी भी हमारे लिए उपयोगी है, लेकिन अब यह संभावित प्रमुख चौराहों से बचाता है। मैंने n को 4 के रूप में चुना, जिसका अर्थ है 16 ^ 4 कैश स्लॉट, कुल कैश आकार से प्रत्येक स्लॉट के लिए औसतन 2kb आवंटित किया गया ( अधिकतम_ 128 = ), जो पर्याप्त होना चाहिए, अन्यथा आपको अधिकतम आकार बढ़ाने की आवश्यकता है।

उपयुक्त स्थान बनाना

 location /x/captcha/generate { proxy_cache captcha; proxy_cache_key "$captcha_salt:$cache_key"; proxy_cache_valid 200 365d; proxy_cache_valid any 0s; proxy_set_header Host "captcha.service.domain.my"; proxy_pass http://captcha_upstream/?cache_key=$cache_key; } 

"अच्छा" बैकएंड प्रतिक्रियाओं को लगभग हमेशा के लिए कैश किया जाएगा, बाकी को कैश नहीं किया जाएगा। और हां, आप तुरंत एक अलग सेवा में कैप्चा के साथ काम करने की कार्यक्षमता को उजागर कर सकते हैं।

वैसे, एक समान तंत्र का उपयोग छद्म गतिशीलता उत्पन्न करने के लिए किया जा सकता है जब उपयोगकर्ता F5 दबाता है और हर बार एक नया यादृच्छिक "चित्र" उसे दिखाया जाता है। इस मामले में, बैकेंड व्यावहारिक रूप से भरा हुआ नहीं है।

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

 location /x/captcha/cache/purge { internal; proxy_cache_purge captcha "$captcha_salt:$arg_cache_key"; } 

इसका आंतरिक निर्देश है, क्योंकि हम इसे सार्वजनिक रूप से उपयोग नहीं करने जा रहे हैं। और इस स्थान को कॉल करने के लिए , हम http_mirror_module मॉड्यूल के दर्पण निर्देश का उपयोग करेंगे:

यही है, हम चर $ arg_cache_key की कुंजी द्वारा कैश को रीसेट करने के लिए एक समानांतर अनुरोध करते हैं, जो कि फॉर्म में प्रसारित होता है। इसके बाद, हमारे बैकएंड के लिए अनुरोध का अनुरोध किया जहां बाकी प्रसंस्करण किया जाता है।

अनुकूलन का कांटेदार मार्ग

यहां, वास्तव में, मैं एक विषय विकसित करना चाहता था: कैप्चा कोड के सत्यापन और फ़ाइल की वापसी को कैसे अलग किया जाए। गलत अनुरोधों से कैश को कैसे धोया जाए। फिर अधिक से अधिक अनुकूलन करने के लिए, लेकिन यह सब इस तथ्य पर उतरता है कि सामान्य तौर पर हमें अब बैकएंड की आवश्यकता नहीं है ... बिल्कुल ... क्योंकि हमारे पास पहले से ही सब कुछ है।

कैप्चा सत्यापन के संदर्भ में सर्वर के साथ जो कार्य रहा, वह वास्तव में कुंजी + कोड की जांच कर रहा है और इस जोड़ी को रिपॉजिटरी से निकाल रहा है। कुंजी + कोड की जांच करना कुंजी के साथ md5 राशि की एक सरल तुलना हो सकती है। इसके लिए, एक मॉड्यूल हमारे लिए पर्याप्त है: http_secure_link_module । यही है, कुंजी को एक सूत्र के रूप में दर्शाया जा सकता है:

उसी समय, कैश स्लॉट (कैश की) को बाध्य करने से हमें कोई नुकसान नहीं होगा, हम इसे जोड़ते हैं:

हमारे पास नमक है - यह $ कैप्चा_साल्ट चर है (इसलिए यह काम आया), लेकिन बैकेंड और प्रॉक्सी पर दो जगहों पर नमक रखना बुरा है, तो चलिए यह करते हैं:

 location /x/captcha/salt { allow {{ captcha backend IPs }}; deny all; return 200 "$captcha_salt"; } 

और बैकएंड को नमक के लिए प्रॉक्सी पर जाने दें।

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

कोड की जाँच

स्थान फ़ाइल डाउनलोड फिर से करें:

 location /download { proxy_set_header Host $host; proxy_set_header X-Context download; proxy_set_header X-File-Name $arg_filename; proxy_set_header X-Key $arg_key; proxy_set_header X-Code $arg_code; proxy_set_header X-Cache-Key $arg_cache_key; proxy_pass http://127.0.0.1/x/captcha/check; proxy_intercept_errors on; error_page 403 404 = /download/fail; } 

मैं हेडर के साथ आवश्यक पैरामीटर पास करता हूं। यह वैकल्पिक है, लेकिन यह मेरे लिए अधिक सुविधाजनक है। हम कैप्चा चेक के स्थानीय स्थान पर प्रोसेसिंग को प्रॉक्सी करते हैं। इसके अतिरिक्त, संदर्भ = डाउनलोड पारित किया गया है, ताकि हैंडलर में हम इसके आधार पर एक या दूसरे परिणाम का उत्पादन कर सकें। इस मामले में, हैंडलर हमारे पास वापस आ सकता है:

• 403 - कोड सत्यापन त्रुटि। दरअसल, इसलिए, प्रॉक्सी_डेनसेप्ट_रियर्स शामिल है और त्रुटि के मामले में पुनर्निर्देशन के लिए एक स्थान घोषित किया जाता है;
• 404 - कैश सफाई त्रुटि। अगर कैश में ऐसा कुछ भी नहीं है तो कैश_पुरेज मॉड्यूल 404 है।
• 200 + एक्सेल-रीडायरेक्ट - फाइल अपलोड के स्थान पर, अगर कैप्चा चेक ठीक चला। हमारे मामले में, यह एक्स-एक्सेल-रीडायरेक्ट: / स्टोर / फ़ाइल होगा

अगर error_page 2XX कोड संभाल सकता है, तो कोई भी इसे अकेले कर सकता है। अन्यथा, आपको एक्सेल-रीडायरेक्ट तंत्र का उपयोग करने की आवश्यकता है। यदि आप वास्तव में चाहते हैं, तो आप 403 और 404 त्रुटि हैंडलर को अलग कर सकते हैं;

एक साधारण स्थान त्रुटि करना:

 location /download/fail { internal; return 200 "FAIL DOWNLOAD"; } 

आप अपनी आवश्यकताओं के आधार पर इस स्थान में कुछ भी वापस कर सकते हैं।

हम फ़ाइल अपलोड का स्थान बनाते हैं:

 location /store/file { internal; add_header Content-Disposition "attachment; filename=\"$arg_filename\""; alias /spool/tmp/; try_files $arg_filename =404; } 

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

कैप्चा सत्यापन के लिए हमारे पास निम्न स्थान है :

 location /x/captcha/check { allow 127.0.0.1; deny all; secure_link_md5 "$captcha_salt$http_x_code$http_x_cache_key"; secure_link $http_x_key; if ($secure_link = "") { return 403 "FAIL CHECK CODE"; } proxy_set_header Host $host; proxy_pass http://127.0.0.1/x/captcha/purge; } 

इसके 2 ब्लॉक हैं: कोड सत्यापन और आगे कैश को खाली करने के लिए। उसी समय, यदि कोड चेक पास नहीं हुआ, तो तुरंत 403 वापस करें (पाठ महत्वहीन है, क्योंकि इसका आगे उपयोग नहीं किया गया है)।

/ X / captcha / purx के लिए 2 उत्तर विकल्प लौटाएगा:

• 200 + एक्सेल-रीडायरेक्ट - सफल कैश फ्लशिंग पर। पुनर्निर्देशन एक्स-एक्सेल-रीडायरेक्ट में होगा: / x / कैप्चा / चेक / ओके ;
• 404 - अगर साफ करने के लिए कुछ भी नहीं था। यह परिणाम / डाउनलोड से ऊपर पारित किया जाएगा और इसे error_page में संसाधित किया जाएगा;

/ X / captcha / purge से सकारात्मक प्रतिक्रिया के लिए एक अलग हैंडलर इस तथ्य के कारण बनाया गया है कि सबसे पहले हमें एक उच्च स्तर तक पहुंचने की आवश्यकता है, और / download / / x / captcha / check के बीच नहीं। दूसरे, संदर्भ के बारे में अपना सकारात्मक जवाब देना अच्छा होगा।

आइए एक सकारात्मक प्रतिक्रिया हैंडलर से शुरू करें:

 location /x/captcha/check/ok { internal; if ( $http_x_context = 'download' ) { add_header X-Accel-Redirect "/store/file?filename=$http_x_file_name"; } ... return 200 "OK"; } 

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

कैश को साफ़ करना काफी सरल है:

 location /x/captcha/purge { allow 127.0.0.1; deny all; proxy_cache_purge captcha "$http_x_cache_key"; add_header X-Accel-Redirect "/x/captcha/check/ok"; } 

सामान्य तौर पर, यह सब, अंत में हमें निम्नलिखित nginx कॉन्फ़िगरेशन मिला:

 proxy_cache_path /cache/nginx/captcha levels=1:1 keys_zone=captcha:10m max_size=128m; server { ... location /download { proxy_set_header Host $host; proxy_set_header X-Context download; proxy_set_header X-File-Name $arg_filename; proxy_set_header X-Key $arg_key; proxy_set_header X-Code $arg_code; proxy_set_header X-Cache-Key $arg_cache_key; proxy_pass http://127.0.0.1/x/captcha/check; proxy_intercept_errors on; error_page 403 404 = /download/fail; } location /download/fail { internal; return 200 "FAIL DOWNLOAD"; } location /store/file { internal; add_header Content-Disposition "attachment; filename=\"$arg_filename\""; alias /spool/tmp/; try_files $arg_filename =404; } ... set $captcha_salt 'salt'; if ( $request_id ~* "(\w{4})$" ) { set $cache_key $1; } location /x/captcha/generate { proxy_cache captcha; proxy_cache_key "$captcha_salt:$cache_key"; proxy_cache_valid 200 365d; proxy_cache_valid any 0s; proxy_set_header Host "captcha.service.domain.my"; proxy_pass http://captcha_upstream/?cache_key=$cache_key; } location /x/captcha/salt { allow {{ captcha backend IPs }}; deny all; return 200 "$captcha_salt"; } location /x/captcha/check { allow 127.0.0.1; deny all; secure_link_md5 "$captcha_salt$http_x_code$http_x_cache_key"; secure_link $http_x_key; if ($secure_link = "") { return 403 "FAIL CHECK CODE"; } proxy_set_header Host $host; proxy_pass http://127.0.0.1/x/captcha/purge; } location /x/captcha/check/ok { internal; if ( $http_x_context = 'download' ) { add_header X-Accel-Redirect "/store/file?filename=$http_x_file_name"; } ... return 200 "OK"; } location /x/captcha/purge { allow 127.0.0.1; deny all; proxy_cache_purge captcha "$http_x_cache_key"; add_header X-Accel-Redirect "/x/captcha/check/ok"; } } 

आपको किन बातों पर ध्यान देना चाहिए:

• Accel-Redirect केवल तभी काम करता है जब प्रतिक्रिया की स्थिति 2XX हो। सच है, अफसोस, इसके बारे में कहीं भी कुछ भी नहीं लिखा गया है, और नेग्नेक्स अनुयायी असहमत हैं;
• निजी स्थान करीब या तो 127.0.0.1 अनुमति देते हैं; इनकार करते हैं सभी; या तो आंतरिक; , इस पर निर्भर करता है कि क्या हम इस स्थान को प्रॉक्सी_पास , या एक्सेल-रीडायरेक्ट के माध्यम से प्राप्त करते हैं ;
• कैप्चा से जुड़े सभी स्थानों को / x / capcha / ... में हाइलाइट किया गया है, ताकि एक माइक्रोसैस सर्विस बनाना संभव हो सके;

स्पष्टता के लिए, मैंने काम का एक चित्र भी बनाया:

सारांश

नतीजतन, बैकएंड से हमें केवल इसके लिए सीधे छवि और कोड उत्पन्न करने की आवश्यकता है। Nginx आराम से संभाल सकता है। बेशक, ये अपेक्षाकृत सरल तार्किक संचालन हैं, लेकिन फिर भी, यह काम को गति देगा और बैकएंड पर लोड को कम करेगा। और वास्तव में, हमने किसी भी असामान्य तंत्र का उपयोग नहीं किया, लेकिन केवल:

• proxy_cache;
• एक्सेल-पुनर्निर्देशन;
• error_page;
• secure_link;
• cache_purge;

बाकी तार्किक श्रृंखलाओं का सही निर्माण है।

हमने कोड और वन-टाइम लिंक के लिए अस्थायी बैकेंड रिपॉजिटरी को भी हटा दिया। हालांकि, उन्होंने नगनेक्स प्रणाली का एक अनिवार्य तत्व बनाया, जिससे उसका कार्यात्मक वजन बढ़ गया।