403 में मना करने पर कर्ल और विकट परिणाम क्यों होगा?

57

मैं के साथ एक फ़ाइल डाउनलोड करने का प्रयास wgetऔर curlऔर यह एक 403 त्रुटि (निषिद्ध) के साथ खारिज कर दिया है।

मैं उसी मशीन पर वेब ब्राउज़र का उपयोग करके फ़ाइल देख सकता हूं।

मैं अपने ब्राउज़र के उपयोगकर्ता एजेंट के साथ फिर से कोशिश करता हूं, जो http://www.whatsmyuseragent.com द्वारा प्राप्त किया गया है । मैं यह करता हूँ:

wget -U 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

तथा

curl -A 'Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0' http://...

लेकिन यह अभी भी मना है। 403 के लिए और क्या कारण हो सकते हैं, और मैं उन्हें दूर करने के लिए किन तरीकों wgetऔर curlआदेशों को बदल सकता हूं ?

(यह फ़ाइल प्राप्त करने में सक्षम होने के बारे में नहीं है - मुझे पता है कि मैं इसे अपने ब्राउज़र से बचा सकता हूं; यह समझने के बारे में है कि कमांड-लाइन टूल अलग तरीके से क्यों काम करते हैं)

अपडेट करें

इस प्रश्न के लिए दिए गए सभी उत्कृष्ट उत्तरों के लिए धन्यवाद। मुझे जो विशिष्ट समस्या आई थी, वह यह थी कि सर्वर रेफ़रर की जाँच कर रहा था। इसे कमांड-लाइन में जोड़कर मैं फ़ाइल का उपयोग करके प्राप्त कर सकता हूं curlऔर wget।

सर्वर है कि रेफरर जाँच की किसी अन्य स्थान कि सभी में कोई जांच निष्पादित करने के लिए एक 302 के माध्यम से बाउंस, तो एक curlया wgetकि साइट के सफाई से काम किया।

अगर किसी को दिलचस्पी है, तो इस बारे में आया क्योंकि मैं एम्बेडेड सीएसएस के बारे में जानने के लिए इस पृष्ठ को पढ़ रहा था और उदाहरण के लिए साइट के सीएसएस को देखने की कोशिश कर रहा था। मैं जिस वास्तविक URL से परेशान हो रहा था, वह यह था और curlमैंने इसे समाप्त कर दिया है

curl -L -H 'Referer: http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

और wget है

 wget --referer='http://css-tricks.com/forums/topic/font-face-in-base64-is-cross-browser-compatible/' http://cloud.typography.com/610186/691184/css/fonts.css

बहुत ही रोचक।

wget curl

— starfry
स्रोत

7

चेक रेफ़र करने वाले पृष्ठ वास्तव में कष्टप्रद होते हैं। हेडर को वैकल्पिक माना जाता है और आंकड़ों को इकट्ठा करने के लिए उपयोग किया जाता है।

— zaadeh

मैंने जो सबसे आसान चीज पाई है, वह है इसे जिप फाइल में बदलना और इसे इस तरह इस्तेमाल करना।

— पानीिनि

40

HTTP अनुरोध में अधिक हेडर हो सकते हैं जो कर्ल या विग द्वारा सेट नहीं किए जाते हैं। उदाहरण के लिए:

कुकी: यह सबसे संभावित कारण है कि किसी अनुरोध को अस्वीकार कर दिया जाएगा, मैंने इसे डाउनलोड साइटों पर देखा है। कुकी को देखते हुए key=val, आप इसे -b key=val(या --cookie key=val) विकल्प के साथ सेट कर सकते हैं curl।
Referer (sic): किसी वेब पेज पर किसी लिंक पर क्लिक करने पर, अधिकांश ब्राउजर करंट पेज को रेफरर के रूप में भेजते हैं। इस पर भरोसा नहीं किया जाना चाहिए, लेकिन जब भी यह हेडर अनुपस्थित था, तब भी ईबे पासवर्ड रीसेट करने में विफल रहा। तो हाँ, ऐसा हो सकता है। इसके लिए curlविकल्प है -e URLऔर --referer URL।
प्राधिकरण: उपयोगकर्ता नाम / पासवर्ड संवाद के बेकाबू यूआई के कारण यह अब कम लोकप्रिय हो रहा है, लेकिन यह अभी भी संभव है। इसे (या ) विकल्प के curlसाथ सेट किया जा सकता है।-u user:password--user user:password
उपयोगकर्ता-एजेंट: कुछ अनुरोध उपयोगकर्ता एजेंट के आधार पर विभिन्न प्रतिक्रियाओं का उत्पादन करेंगे। इसका उपयोग अच्छे तरीके से किया जा सकता है (दर्पण की सूची के बजाय वास्तविक डाउनलोड प्रदान करना) या खराब तरीके से (उपयोगकर्ता एजेंटों को अस्वीकार करना जो शुरू नहीं Mozillaहोते हैं, या होते हैं Wgetया होते हैं curl)।

आप आमतौर पर अपने ब्राउज़र द्वारा भेजे गए हेडर को पढ़ने के लिए अपने ब्राउज़र के डेवलपर टूल (फ़ायरफ़ॉक्स और क्रोम इस का समर्थन करते हैं) का उपयोग कर सकते हैं। यदि कनेक्शन एन्क्रिप्ट नहीं किया गया है (जो कि HTTPS का उपयोग नहीं कर रहा है), तो आप इस उद्देश्य के लिए एक पैकेट स्निफर जैसे कि विंडसरक का भी उपयोग कर सकते हैं।

इन हेडर के अलावा, वेबसाइटें राज्य को बदलने वाले दृश्यों के पीछे कुछ कार्यों को भी ट्रिगर कर सकती हैं। उदाहरण के लिए, एक पृष्ठ खोलते समय, यह संभव है कि डाउनलोड लिंक तैयार करने के लिए पृष्ठभूमि पर एक अनुरोध किया जाए। या पेज पर एक रीडायरेक्ट होता है। ये क्रियाएं आम तौर पर जावास्क्रिप्ट का उपयोग करती हैं, लेकिन इन कार्यों को सुविधाजनक बनाने के लिए एक छिपा हुआ फ्रेम भी हो सकता है।

आप देख रहे हैं एक विधि को आसानी से एक डाउनलोड साइट से फ़ाइलें लाने के लिए के लिए, plowdown पर एक नज़र, के साथ शामिल है plowshare ।

— Lekensteyn
स्रोत

एक और वास्तव में विकृत संभावना यह होगी कि किसी कारण से सर्वर को सफलता पर 200 के बजाय 403 वापस करने के लिए कॉन्फ़िगर किया गया था।

— कैस्परल्ड

1

इससे मुझे वह सुराग मिला जिसकी मुझे जरूरत थी। कुकीज़ की कोशिश करने के बाद, मैंने रेफर को समस्या के रूप में पाया (अब, यदि केवल इसे ठीक से वर्तनी किया जा सकता है !!!)

— Starfry

2

यदि यह अभी भीwget जोड़ने की कोशिश में असफल हो रहा है --auth-no-challenge। जादू की तरह काम करता है।

— जोनाथन 2

13

बस उपरोक्त उत्तरों को जोड़ना चाहते हैं कि आप क्रोम डेवलपर टूल (v26.0 के बाद से) और फायरबग ( v1.12 के बाद से) में मौजूद "कॉपी के रूप में कॉपी" सुविधा का उपयोग कर सकते हैं । आप नेटवर्क टैब में अनुरोध पंक्ति को राइट-क्लिक करके इस सुविधा तक पहुंच सकते हैं।

— solde9
स्रोत

इससे क्रोम में विशेष रूप से टूल को काफी मदद मिली। जब मैंने फ़ायरफ़ॉक्स में कोशिश की, तो 302 के बाद अनुरोध हैडर मैं सब देख सकता था। क्रोमियम में मैं दोनों को देख सकता था और इससे मुझे समस्या को हल करने की जानकारी मिली।

— स्टार

1

@starfry Enable persistent logsफ़ायरफ़ॉक्स के देव टूल के सेटिंग टैब पर टिक करने की आवश्यकता है ताकि इसे रीडायरेक्ट पर नेटवर्क लॉग को साफ़ करने से रोका जा सके। क्रोम में एक समान विकल्प है। संयोग से, "कॉपी रूप cURL" फ़ायरफ़ॉक्स नाइटली / ऑरोरा / बीटा में कुछ समय के लिए रहा है, और यह अगले प्रमुख रिलीज (31.0) के कारण है।

— बॉब

9

उपरोक्त सभी की कोशिश की, हालांकि कोई भाग्य नहीं; उपयोगकर्ता-एजेंट स्ट्रिंग प्राप्त करने के लिए देव ब्राउज़र टूल का उपयोग किया, एक बार मैंने निम्नलिखित को जोड़ा, सफलता:

--user-agent="Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36"

— user3707737
स्रोत

5

आप जो मांग रहे हैं, उसके आधार पर यह एक कुकी हो सकती है। फ़ायरफ़ॉक्स के साथ, आप प्रश्न में पृष्ठ पर एक राइट-क्लिक कर सकते हैं, "पेज जानकारी देखें"। "सुरक्षा" आइकन चुनें, और फिर "कुकी देखें" बटन पर क्लिक करें।

कुकीज़ को बाहर निकालने के लिए, फ़ायरफ़ॉक्स "लाइव HTTP हेडर्स" प्लग-इन आवश्यक है। आप देख सकते हैं कि कुकीज़ क्या सेट करती हैं, और क्या कुकीज़ वेब सर्वर पर वापस भेज दी जाती हैं।

wgetकुकीज़ के साथ काम कर सकते हैं, लेकिन यह पूरी तरह से infurating है, क्योंकि यह एक संकेत नहीं देता है कि यह कुकीज़ नहीं भेजती है। आपकी सबसे अच्छी शर्त यह है कि आप अपने ब्राउज़र से सभी संबंधित कुकीज़ हटा दें, और जो कुछ भी प्रारंभिक लॉगिन या पृष्ठ देखने के अनुक्रम से गुजरता है। कुकीज़ के लिए "लाइव HTTP हेडर" को देखें, और किसी भी पोस्ट या जीईटी मापदंडों के लिए। wget"-की-सत्र-कुकीज़" और "- सेव-कुकीज" विकल्पों का उपयोग करके पहला लॉगिन करें। यह आपको एक कुकी फ़ाइल देगा जिसे आप टेक्स्ट एडिटर के साथ देख सकते हैं। wget --load-cookiesअगले चरणों के लिए कुकी फ़ाइल का उपयोग करें।

— ब्रूस एडिगर
स्रोत

1

मैंने एक निजी ब्राउज़िंग विंडो खोलकर फ़ायरफ़ॉक्स में कुकीज़ के बिना परीक्षण किया और उम्मीद के मुताबिक मुझे 403 त्रुटि मिली। दिलचस्प है कि आपको नए टैब में त्रुटि नहीं मिलती है। क्रोमियम में, एक नया टैब 403 रिटर्न

— starfry

1

संयोग से, आप फ़ायरफ़ॉक्स के देव टूल्स के नेटवर्क टैब का उपयोग बिना किसी एडऑन के भेजे और प्राप्त कुकीज़ का निरीक्षण करने के लिए कर सकते हैं। क्रोम / क्रोमियम के लिए डिट्टो।

— बॉब

@ बूब - हां मुझे वह मिला। मुझे कुछ ही मिनट लगे क्योंकि यह कुछ नहीं था। फायरबग की प्रतिलिपि अब CURL के रूप में है लेकिन इसे देशी उपकरण भी देखना अच्छा होगा।

— स्टार

1

यह तब हो सकता है जब साइट को SSL की आवश्यकता होती है। आपका ब्राउज़र स्वचालित रूप से HTTP से HTTPS तक आगे बढ़ जाएगा लेकिन कर्ल और विग नहीं होगा। इसलिए HTTP के बजाय HTTPS के साथ अनुरोध का प्रयास करें।

— रिचर्ड
स्रोत

3

अगर मैं सही हूं तो यह गलती से 301 या 302, रीडायरेक्ट में समाप्त हो जाएगा।

— जकूजी