प्रोक्सी बदल्नाले स्पाइडरका कुकीहरू स्वतः बदलिँदैनन्। यो एउटा चलिरहेको सत्रका लागि उपयोगी हुन सक्छ र धेरै स्वतन्त्र सत्रहरूले एउटै स्पाइडर साझा गर्दा आश्चर्यजनक लाग्छ।

Scrapy को कुकी मिडलवेयरले अनुरोधको cookiejar मेटाडेटाबाट छानिएका अलग जारहरूलाई समर्थन गर्छ। त्यो कुञ्जीलाई तपाईंले साँच्चै सुरक्षित राख्न चाहेको पहिचान दिनुहोस्:

yield scrapy.Request(
    'https://example.com/start',
    meta={'proxy': selected_proxy, 'cookiejar': 'workflow-17'},
)

इन्डपोइन्ट र जार-कुञ्जी दुई स्वतन्त्र छनोट हुन्। अप्रमाणित सार्वजनिक क्रलले आफ्नो छानिएको HTTP इन्डपोइन्ट HTTP प्रोक्सी सूचीबाट लिन सक्छ जहाँ त्यो मार्ग अनुमति छ; कार्यप्रवाह अझै जार-कुञ्जीको मालिक हुन्छ। यो सत्रमा रहनुपर्ने पछिल्लो अनुरोधलाई त्यही जार-कुञ्जी चाहिन्छ; तपाईंले बनाउनुहुने हरेक नयाँ अनुरोधमा मेटाडेटा स्वतः टाँसिँदैन। सबै मिडलवेयर मेटाडेटा अन्धाधुन्ध प्रतिलिपि गर्नुको सट्टा कार्यप्रवाहलाई आवश्यक पर्ने विशेष फिल्डहरू अगाडि बढाउनुहोस्।

प्रोक्सी ठेगाना जार-कुञ्जी बनाउनु एउटा मात्र नीति हो

त्यो सर्टकटले अवस्थालाई इन्डपोइन्टअनुसार समूहबद्ध गर्छ। यसले व्यक्ति, खाता वा सार्वजनिक निकासअनुसार समूहबद्ध गर्छ भन्ने छैन। एउटा प्रदायक इन्डपोइन्टले निकास घुमाउन सक्छ, र धेरै खाताले एउटै इन्डपोइन्ट प्रयोग गर्न सक्छन्।

स्थिर अवस्था चाहिने अधिकृत कार्यप्रवाहका लागि खाता/सत्र पहिचानकर्ता, जार पहिचानकर्ता र छानिएको मार्ग अलग-अलग अभिलेख गर्नुहोस्। यदि तपाईंले बीच बाटोमा मार्ग बदल्ने निर्णय गर्नुभयो भने अनुप्रयोग सत्रलाई के हुनुपर्छ पनि निर्णय गर्नुहोस्।

अलग जारहरूले तपाईंले परिभाषित गरेका समूहहरूबीच कुकीहरू दुर्घटनावश साझा हुनबाट रोक्छन्। तर कुनै गन्तव्यले खाता वा अन्य अनुप्रयोग डेटामार्फत दुई अनुरोधहरू जोड्न सक्दैन भन्ने वाचा तिनीहरूले गर्दैनन्।

IP बदलेपछि पनि गलत पृष्ठ रहिरहेमा सबै कुकी मेट्नु वा सम्पूर्ण प्रोक्सी पूल बदल्नु अघि कुन जारले अनुरोध पठायो जाँच्नुहोस्। राखिएको अवस्थाले पृष्ठलाई राम्ररी व्याख्या गर्न सक्छ।

सम्बन्धित लेखहरू