उस HAR फ़ाइल को भेजने से पहले, पढ़ लें कि उसके अंदर क्या है
"क्या आप हमें एक HAR फ़ाइल भेज सकते हैं?" एक उचित अनुरोध है — और रोज़मर्रा के सहायता कार्य में सबसे लापरवाही से खतरनाक फ़ाइल हस्तांतरणों में से एक भी। HAR फ़ाइल ब्राउज़र सत्र की पूर्ण रिकॉर्डिंग है: हर अनुरोध और हर जवाब, उन कुकीज़, प्राधिकरण हैडर, टोकन और फ़ॉर्म सामग्री के साथ जिन्होंने उन्हें काम करने लायक बनाया। यह ठीक वही है जो किसी सहायता इंजीनियर को आपकी समस्या को दोहराने के लिए चाहिए, और ठीक वही है जो कोई हमलावर आपके सत्र को दोहराने के लिए चाहेगा। यह लेख बताता है कि HAR फ़ाइल क्या है, Chrome, Edge या Firefox में एक को कैसे कैप्चर करें, वह क्या लीक करती है, और कहीं जाने से पहले उसे कैसे जाँचें और संपादित करें।
HAR फ़ाइल क्या है
HAR — HTTP Archive — HTTP ट्रैफ़िक को रिकॉर्ड करने का एक JSON प्रारूप है, जो HAR 1.2 विनिर्देश में मानकीकृत है और हर प्रमुख ब्राउज़र के विकासक उपकरणों तथा mitmproxy जैसे डीबगिंग प्रॉक्सी द्वारा निर्यात किया जाता है। फ़ाइल में एक log ऑब्जेक्ट होता है जिसकी entries सरणी होती है: प्रति अनुरोध एक प्रविष्टि, हर एक में विधि और पूर्ण URL, अनुरोध और जवाब के हैडर, दोनों दिशाओं की कुकीज़, पैरामीटरों में विभाजित क्वेरी स्ट्रिंग, कोई भी POST बॉडी, जवाब की स्थिति, आकार और सामग्री प्रकार, और चरण-वार विभाजित समय — DNS, कनेक्शन, TLS, भेजना, प्रतीक्षा, प्राप्ति।
दूसरे शब्दों में, यह समस्या का स्क्रीनशॉट नहीं है; यह समस्या स्वयं है, दोबारा चलाई जा सकने वाली। HTTP ट्रैफ़िक का उपभोग करने वाली हर चीज़ इस प्रारूप के साथ काम करती है — ब्राउज़र उपकरण, प्रदर्शन विश्लेषक, सहायता इंजीनियर, और बढ़ते हुए, एजेंट: क्या AI एजेंट आपके ऐप की रिवर्स इंजीनियरिंग कर सकते हैं? में शामिल REA स्टैक HAR कैप्चर को मूल रूप से पढ़ता है, क्योंकि कई ऐप के लिए API ट्रैफ़िक कोड से अधिक समझाता है। यही उपयोगिता वह कारण है कि फ़ाइल भेजे जाने योग्य होने से पहले पढ़े जाने योग्य है।
सहायता टीमें और विक्रेता एक क्यों माँगते हैं
क्योंकि यह बहसें समाप्त कर देती है। "पृष्ठ धीमा था" नामित अनुरोधों और समयों वाला एक झरना बन जाता है। "API विफल हो गई" वह ठीक अनुरोध बन जाती है जिसने 500 दिया, ठीक पेलोड और ठीक हैडर के साथ। "मेरी मशीन पर काम करता है" मायने रखना बंद कर देता है, क्योंकि रिकॉर्डिंग आपकी मशीन, आपके नेटवर्क, आपके खाते से है, उस क्षण की जब वह टूटी। एक अच्छा सहायता इंजीनियर एक ईमानदार HAR फ़ाइल से एक सप्ताह के स्क्रीनशॉट और यादों से अधिक कर सकता है।
इसीलिए यह अनुरोध इतनी बार बिना सोचे आगे भी भेज दिया जाता है। टिकट कहता है "एक HAR जोड़ें", उपयोगकर्ता तीस सेकंड में एक निर्यात कर देता है, और फ़ाइल — जब वह लॉग इन था, असली काम कर रहा था, तब रिकॉर्ड की गई — यात्रा शुरू कर देती है: एक टिकट प्रणाली में, एक ईमेल धागे में, कभी किसी सार्वजनिक फ़ोरम या साझा ड्राइव पर, हर छलांग पर प्रतियाँ जमा करते हुए। उस श्रृंखला में कोई भी ठीक-ठीक लापरवाह नहीं है; प्रारूप बस छिपा देता है कि उसमें क्या है। .har फ़ाइल निष्क्रिय नैदानिक डेटा जैसी लगती है। यह चाबियों के गुच्छे के अधिक निकट है।
Chrome, Edge या Firefox में एक कैसे कैप्चर करें
Chrome या Edge में: पृष्ठ खोलें, DevTools के लिए F12 दबाएँ, और नेटवर्क पैनल पर जाएँ (Chrome DevTools नेटवर्क संदर्भ हर नियंत्रण का दस्तावेज़ीकरण करता है)। सुनिश्चित करें कि लाल रिकॉर्ड बटन चालू है और यदि समस्या किसी नेविगेशन में फैली है तो लॉग संरक्षित करें पर टिक करें। समस्या को एक बार, शुरू से अंत तक दोहराएँ। फिर सूची में किसी भी अनुरोध पर दायाँ-क्लिक करें और सभी को सामग्री सहित HAR के रूप में सहेजें चुनें (Edge इसे नेटवर्क लॉग सहेजने के रूप में कहता है)। Firefox में प्रवाह का आकार वही है: DevTools → नेटवर्क, दोहराएँ, दायाँ-क्लिक → सभी को HAR के रूप में सहेजें।
दो कैप्चर आदतें किसी भी सेटिंग से अधिक मायने रखती हैं। पहली, वह सबसे छोटा सत्र रिकॉर्ड करें जो समस्या दिखाता है: ब्राउज़िंग का हर अतिरिक्त मिनट फ़ाइल में अतिरिक्त ट्रैफ़िक — और अतिरिक्त रहस्य — है, जिसमें अन्य टैब और पृष्ठभूमि अनुरोध उस समय क्या कर रहे थे यह भी शामिल है। दूसरी, यदि आप कर सकें, तो समस्या को एक नए ब्राउज़र प्रोफ़ाइल या निजी विंडो में दोहराएँ, केवल संबंधित सेवा में साइन इन करके। एक स्वच्छ प्रोफ़ाइल से कैप्चर में केवल वह एक सत्र होता है और कुछ नहीं: कोई बैंकिंग टैब नहीं, कोई वेबमेल नहीं, अन्य ऐप के टोकन अंदर यात्रा नहीं करते।
वह क्या लीक करती है
सबसे पहले, आपका सत्र। Cookie और Set-Cookie हैडर और कुकी सूचियाँ आपके सत्र पहचानकर्ता रखती हैं, और अधिकांश सत्र कुकीज़ सबसे सीधे अर्थ में धारक क्रेडेंशियल हैं: जो एक प्रस्तुत करता है उसे उसके समाप्त होने या रद्द किए जाने तक आप ही माना जाता है। Authorization हैडर धारक टोकन और कभी-कभी Basic क्रेडेंशियल जोड़ता है। प्रारूप में कुछ भी इन मानों को विशेष के रूप में चिह्नित नहीं करता; वे बस हैडर हैं, वफ़ादारी से रिकॉर्ड किए गए।
फिर वे चीज़ें जिन्हें कोई हैडर नहीं मानता। टोकन हर समय URL में यात्रा करते हैं — API कुंजियाँ, पासवर्ड-रीसेट और ईमेल-सत्यापन लिंक, हस्ताक्षरित डाउनलोड URL, OAuth कॉलबैक — और HAR पूर्ण URL के साथ-साथ आसान पढ़ने के लिए विभाजित क्वेरी स्ट्रिंग रिकॉर्ड करती है। POST बॉडी वह रखती हैं जो फ़ॉर्म रखते थे: कैप्चर के दौरान आपने जिस पासवर्ड से लॉग इन किया, प्रोफ़ाइल संपादन, संदेश, व्यक्तिगत डेटा। जवाब बॉडी उसी वर्ग का डेटा वापस ला सकती हैं। एक वास्तविक सत्र की HAR फ़ाइल, वास्तव में, आपके खाते की आंशिक प्रतिलिपि है — इसीलिए नेटवर्क पर तार पर ट्रैफ़िक पढ़ने वाले उपकरण, जैसे PCAP Analyzer, और उसे ब्राउज़र में पढ़ने वाले, जैसे यह पृष्ठ, क्रेडेंशियल को स्पष्ट रूप से दिखाने के लिए बने हैं, ताकि आप देख सकें कि आप क्या पकड़े हुए हैं।
भेजने से पहले उसे जाँचें और संपादित करें
तो: फ़ाइल को किसी और से पहले खोलें। इस साइट का HAR File Analyzer ठीक इसी के लिए है — .har को पृष्ठ में डालें और वह स्थानीय रूप से, आपके उपकरण पर पार्स होती है, कभी अपलोड नहीं होती, संवेदनशील मान डिफ़ॉल्ट रूप से छिपाए गए: Authorization, Cookie और Set-Cookie हैडर, हर कुकी मान, और हर वह हैडर, क्वेरी पैरामीटर, फ़ॉर्म फ़ील्ड या JSON कुंजी जिसका नाम टोकन, कुंजी, रहस्य, सत्र या पासवर्ड जैसा लगे। सारांश और सबसे धीमे व सबसे बड़े अनुरोधों को सरसरी तौर पर देखें; जाँचें कि कौन से होस्ट दिखाई देते हैं — कैप्चर में कभी-कभी उन साइटों का ट्रैफ़िक होता है जिन्हें आप देख भी नहीं रहे थे — और यदि आपको पुष्टि करनी हो कि वास्तव में अंदर क्या है, तो केवल अपनी स्क्रीन पर "मान दिखाएँ" टॉगल का उपयोग करें।
फिर संपादित .har डाउनलोड करें और उसके स्थान पर वही भेजें। संपादन उस संरचना को बनाए रखता है जिसकी सहायता इंजीनियर को आवश्यकता है — वही प्रविष्टियाँ, हैडर, आकार के रूप में URL, स्थितियाँ और समय — और क्रेडेंशियल मानों को शाब्दिक पाठ REDACTED से बदल देता है, हैडर, कुकीज़, क्वेरी स्ट्रिंग, फ़ॉर्म डेटा और JSON बॉडी में समान रूप से। एक सीमा उपकरण पर छपी है और यहाँ दोहराई जाती है: जो POST बॉडी न JSON है न साधारण फ़ॉर्म डेटा, उसे सुरक्षित रूप से पार्स नहीं किया जा सकता, इसलिए वह अपरिवर्तित आगे बढ़ जाती है — यदि आपके कैप्चर में ऐसी बॉडी है, तो फ़ाइल के यात्रा करने से पहले उसे स्वयं पढ़ें। छिपाया गया CSV सारांश उसी कारण से मौजूद है: यह वह फ़ाइल है जो आप तब जोड़ते हैं जब इंजीनियर "केवल अनुरोधों की सूची" माँगता है।
संपादन क्या नहीं कर सकता
संपादन चाबियाँ हटा देता है; यह नक्शा नहीं हटाता। एक संपादित HAR अब भी आपके होस्ट और एंडपॉइंट, आपके पैरामीटर नाम, जवाबों का आकार और माप, कॉलों का क्रम और समय दिखाती है — आपके एप्लिकेशन के API का एक कार्यशील रेखाचित्र, जो स्वयं ऐसी जानकारी हो सकती है जिसे आप प्रकाशित नहीं करते। यह प्रतियाँ भी वापस नहीं बुला सकती: एक बार कच्ची फ़ाइल किसी टिकट प्रणाली या इनबॉक्स में चली गई, तो अपनी प्रति को संपादित करने से उनकी प्रति में कुछ नहीं बदलता। संपादित फ़ाइल को विक्रेता द्वारा दिए गए निजी माध्यम से साझा करें — स्वयं टिकट, कोई सार्वजनिक पोस्ट या सार्वजनिक फ़ाइल लिंक नहीं — और टिकट में, मामला बंद होने पर फ़ाइल को हटाने का अनुरोध करें। प्रतिष्ठित सहायता संगठन नियमित रूप से ऐसा करते हैं; माँगने में कुछ खर्च नहीं होता।
और यदि एक कच्ची, असंपादित HAR पहले ही निकल गई है — गलत पते पर भेजी गई, किसी सार्वजनिक मुद्दे से जोड़ी गई, साझा फ़ोल्डर में छोड़ी गई — तो सत्र को उजागर माना जाए, क्योंकि वह है: सेवा से साइन आउट करें (जो आमतौर पर सर्वर-पक्ष पर सत्र को अमान्य कर देता है), फिर से साइन इन करें, और उसमें दिखाई दी कोई भी API कुंजी बदल दें। यह किसी भी लीक हुए क्रेडेंशियल के लिए वही नियम है, और यही कारण है कि इस साइट के अन्य फ़ाइल उपकरणों पर छोटा अक्षर समान है — Binary File Inspector निष्पादन योग्य फ़ाइलों को स्थानीय रूप से उसी कारण से पढ़ता है जिस कारण यह पृष्ठ कैप्चर को स्थानीय रूप से पढ़ता है: जिन फ़ाइलों को सबसे अधिक निरीक्षण की आवश्यकता है, वे ठीक वही फ़ाइलें हैं जिन्हें निरीक्षण के लिए अपलोड नहीं किया जाना चाहिए।