Claude Code में संवेदनशील संदर्भ कैसे घटाएँ — व्यावहारिक प्रॉम्प्ट टेम्पलेट, फ़ाइल-शेयरिंग वर्कफ़्लो और रेडैक्शन कदम ताकि आप कम जोखिम में भी उपयोगी कोडिंग सहायता पा सकें।
"संदर्भ" वह सब कुछ है जो आप मॉडल को देते हैं: कोड स्निपेट, स्टैक ट्रेज़, कन्फ़िग फाइलें, एनवायरनमेंट वेरिएबल, डेटाबेस सैंपल, स्क्रीनशॉट और चैट के पहले संदेश। अधिक संदर्भ बग ढूँढने में मदद कर सकता है, लेकिन इससे गलती से आप कुछ ऐसा भी पेस्ट कर सकते हैं जो साझा नहीं करना चाहिए।
अक्सर ओवरशेयरिंग तब होती है जब दबाव होता है। एक बग रिलीज रोक रहा हो, डेमो से ठीक पहले ऑथ ब्रेक हो, या CI में flaky टेस्ट फेल हो रहा हो — ऐसे में पूरा फ़ाइल, पूरा लॉग, या पूरा कन्फ़िग "सिर्फ इन केस" पेस्ट कर देना आसान हो जाता है। टीम की आदतें भी यही प्रेरित कर सकती हैं: कोड समीक्षा और डीबगिंग में पूरी विज़िबिलिटी सामान्य मानी जाती है, भले ही केवल एक छोटा टुकड़ा पर्याप्त हो।
जोखिम काल्पनिक नहीं हैं। एक ही बार का पेस्ट सीक्रेट्स, कस्टमर डेटा, या आंतरिक सिस्टम विवरण लीक कर सकता है। आम उदाहरणों में शामिल हैं:
लक्ष्य गुप्त रहना नहीं है। लक्ष्य वह सबसे छोटा हिस्सा साझा करना है जो इश्यू को दोहराता है या निर्णय समझाने के लिए पर्याप्त है, ताकि कम जोखिम में भी समान गुणवत्ता की मदद मिल सके।
एक सरल मानसिक मॉडल: असिस्टेंट को एक बाहरी सहकर्मी समझें जिसे आपका पूरा रिपो नहीं चाहिए। एक सटीक सवाल के साथ शुरू करें ("यह रिक्वेस्ट क्यों 401 लौटाती है?")। फिर केवल वही शेयर करें जो उस सवाल का समर्थन करे: फेलिंग इनपुट, अपेक्षित आउटपुट, वास्तविक आउटपुट, और संकुचित कोड पाथ।
अगर लॉगिन कॉल फेल हो रही है, तो आपको आम तौर पर पूरा ऑथ मॉड्यूल साझा करने की ज़रूरत नहीं है। एक सैनिटाइज़्ड रिक्वेस्ट/रेस्पॉन्स पेयर, हेडर बनाने वाला फ़ंक्शन, और संबंधित कन्फ़िग कीज़ (मान बदलकर) अक्सर पर्याप्त होते हैं।
जब आप कोडिंग सहायता माँगते हैं, तो "संदर्भ" सिर्फ सोर्स कोड नहीं है। यह वह सब कुछ है जो किसी को लॉगिन करने, किसी व्यक्ति की पहचान करने, या आपके सिस्टम का नक्शा बनाने में मदद कर सकता है। पहले जानें कि क्या टाइप का टेक्स्ट पेस्ट करना जहरीला है।
क्रेडेंशियल्स एक सहायक स्निपेट को किसी घटना में बदल देते हैं। इसमें API कीज़ और टोकन, प्राइवेट कीज़, सत्र कुकीज़, साइन किए हुए URLs, OAuth क्लाइंट सीक्रेट्स, डेटाबेस पासवर्ड, और लॉग्स में प्रिंट हुए "टेम्पररी" टोकन शामिल हैं।
एक सामान्य आश्चर्य अप्रत्यक्ष लीक है। एक त्रुटि संदेश में पूरे रिक्वेस्ट हेडर्स के साथ Authorization bearer टोकन या एनवायरनमेंट वेरिएबल्स का डिबग डम्प शामिल हो सकता है।
किसी व्यक्ति से जुड़ा कोई भी डेटा संवेदनशील हो सकता है, भले ही वह अकेले दिखने पर मामूली लगे। ईमेल, नाम, फोन नंबर, पते, कस्टमर IDs, कर्मचारी IDs, सपोर्ट टिकट, और पेमेंट डिटेल्स पर ध्यान दें।
अगर बग दोहराने के लिए डेटा चाहिए, तो असली रिकॉर्ड के स्थान पर यथार्थवादी नकली रिकॉर्ड का उपयोग करें। संरचना (फील्ड और प्रकार) रखें, पहचान नहीं।
"साधारण" आंतरिक तथ्य हमला करने वालों और प्रतिस्पर्धियों के लिए मूल्यवान होते हैं: होस्टनेम्स, IPs, रेपो नाम, टिकट IDs, विक्रेता नाम, और आंतरिक सर्विस URLs।
एक स्टैक ट्रेस भी फ़ोल्डर पाथ्स में यूजरनेम्स या क्लाइंट नाम, सर्विस नेमिंग कन्वेंशन्स, और क्लाउड अकाउंट संकेत (बकेट नाम, रीजन स्ट्रिंग्स) उजागर कर सकता है।
सभी कोड समान रूप से संवेदनशील नहीं होते। सबसे रिस्की हिस्से वे हैं जो आपके बिज़नेस के काम करने का तरीका एन्कोड करते हैं: प्राइसिंग और डिस्काउंट नियम, फ्रॉड चेक्स, रिकमेंडेशन लॉजिक, LLM फीचर के लिए प्रॉम्प्ट टेम्पलेट, और स्ट्रैटेजिक डॉक।
अगर आपको बग में मदद चाहिए, तो पूरा मॉड्यूल साझा करने की बजाय सबसे छोटा फ़ंक्शन साझा करें जो इसे दोहराता है।
संवेदनशील विवरण अक्सर उन जगहों पर रहते हैं जिनका आप ध्यान नहीं रखते: कमेंट्स में नाम, कमिट मेसेज, ग्राहकों का उल्लेख करने वाले TODOs, और बिना बदले पेस्ट किए गए स्टैक ट्रेसेस। कन्फ़िग फ़ाइलें विशेष रूप से रिस्की होती हैं क्योंकि वे सामान्य सेटिंग्स को सीक्रेट्स के साथ मिक्स कर देती हैं।
एक व्यावहारिक नियम: अगर टेक्स्ट किसी साफ-रूम उदाहरण की तुलना में किसी को आपके सिस्टम को तेज़ी से समझने में मदद करेगा, तो उसे संवेदनशील समझकर redact या replace करें।
सबसे अच्छा समय एक्सपोज़र कम करने का वह समय है जब आप अपना एडिटर खोलने से पहले 30 सेकंड रुकते हैं। एक छोटा सा ब्रेक अक्सर आपके शेयर किए जाने वाले कंटेंट को काफी घटा देता है।
पहले एक वाक्य में बताएं कि आपको क्या परिणाम चाहिए। क्या आप बग का कारण ढूँढना चाहते हैं, सुरक्षित रिफैक्टर प्लान चाहते हैं, या टेस्ट डिजाइन करना चाहते हैं? हर लक्ष्य को अलग इनपुट्स चाहिए। बग हंट्स में आम तौर पर एक स्टैक ट्रेस और एक छोटा फ़ंक्शन चाहिए; रिफैक्टर सवालों के लिए अक्सर केवल पब्लिक इंटरफेसेज़ और उपयोग का छोटा उदाहरण काफी होता है।
फिर एक "न्यूनतम आर्टिफ़ैक्ट" चुनें जो समस्या साबित करे। सबसे छोटा वो चुनें जो अभी भी फेल होता है: एक फेलिंग टेस्ट, त्रुटि ट्रिगर करने वाला सबसे छोटा स्निपेट, विफलता के आसपास का छोटा लॉग अंश, या प्लेसहोल्डर्स के साथ आसान कन्फ़िग सैंपल।
जब आप डेटा वर्णन करें, तो मानों के बजाय आकार बताएं। "User object में id (UUID), email (string), role (enum), createdAt (timestamp) है" अक्सर पर्याप्त होता है। उदाहरणों की ज़रूरत पड़े तो असली रिकॉर्ड की जगह फर्जी उदाहरण दें जो फॉर्मैट से मेल खाते हों।
फाइलों के बारे में कड़ा रूल रखें। केवल वही मॉड्यूल साझा करें जिसे आप बदल रहे हैं और जिन इंटरफेसेज़ को वह छूता है। अगर एक फ़ंक्शन दूसरे मॉड्यूल को कॉल करता है, तो अक्सर आपको केवल सिग्नेचर और यह संक्षेप में क्या रिटर्न करता है यह बताना पर्याप्त होता है। अगर बग किसी अन्य सर्विस को किए गए रिक्वेस्ट से जुड़ा है, तो आप शायद केवल रिक्वेस्ट शिफ और हेडर नामों की सूची (मान नहीं) और अपेक्षित रेस्पॉन्स शिफ साझा करना चाहेंगे।
कभी भी मशीन से बाहर न निकलने वाली चीज़ें तय कर लें: API कीज़, प्राइवेट सर्टिफिकेट्स, एक्सेस टोकन्स, कस्टमर डेटा, आंतरिक URLs, पूर्ण रिपोजिटरी डंप्स, और कच्चे प्रोडक्शन लॉग्स। अगर आप 401 डिबग कर रहे हैं, तो ऑथ फ्लो और त्रुटि संदेश साझा करें, पर टोकन को TOKEN_REDACTED से और ईमेल को [email protected] से बदल दें।
अच्छा रेडैक्शन सिर्फ सीक्रेट छिपाने का नहीं है; यह समस्या की संरचना को बनाए रखता है ताकि असिस्टेंट अभी भी तर्क कर सके। बहुत ज़्यादा हटाने पर आपको सामान्य सुझाव मिलते हैं; बहुत कम हटाने से डेटा लीक का जोखिम बढ़ जाता है।
एक प्लेसहोल्डर स्टाइल चुनें और कोड, कन्फिग, और लॉग्स में उस पर टिके रहें। सुसंगत प्लेसहोल्डर फ़्लो को समझना आसान बनाते हैं।
अगर एक ही टोकन तीन जगह आता है तो उसे तीन अलग तरीकों से बदलने की बजाय API_KEY_1, TOKEN_1, USER_ID_1, CUSTOMER_ID_1, EMAIL_1 जैसा प्रयोग करें और ज़रूरत पड़ने पर बढ़ाएँ (TOKEN_2, TOKEN_3)।
एक छोटा लेजेंड मदद करता है बिना असली मान बताए:
TOKEN_1: Authorization header में उपयोग होने वाला bearer tokenCUSTOMER_ID_1: डेटाबेस लुकअप में उपयोग की जाने वाली आंतरिक ग्राहक पहचानकर्ताAPI_KEY_1: पेमेंट प्रोवाइडर को कॉल करने के लिए उपयोग की गई कीकुछ बग लंबाई और संरचना पर निर्भर करते हैं (पार्सिंग, वैलिडेशन, सिग्नेचर चेक, regex)। उन मामलों में, यूनिक स्ट्रिंग्स को डमी मानों से बदलें जो दिखने में समान हों।
उदाहरण:
यह आपको यह कहने देता है कि "टोकन वैधता फेल कर रहा है" बिना असली टोकन दिखाए।
जब JSON शेयर करें, तो keys रखें और values बदल दें। keys यह दिखाते हैं कि सिस्टम क्या उम्मीद करता है; values अक्सर संवेदनशील होते हैं।
बजाय इसके कि:
{"email":"[email protected]","password":"SuperSecret!","mfa_code":"123456","customer_id":"c8b1..."}
शेयर करें:
{"email":"EMAIL_1","password":"PASSWORD_1","mfa_code":"MFA_CODE_1","customer_id":"CUSTOMER_ID_1"}
SQL के लिए भी यही आइडिया है: तालिका नाम, जॉइन्स और कंडीशंस रखें, लेकिन लिटरल्स हटा दें।
WHERE user_id = USER_ID_1 AND created_at > DATE_1अगर कोई फ़ंक्शन बिज़नेस नियम या प्रोप्राइटरी लॉजिक रखता है, तो उसे टेक्स्ट में समझाएँ। जो कुछ बग को प्रभावित करता है वही रखें: इनपुट्स, आउटपुट्स, साइड-इफेक्ट और त्रुटि हैंडलिंग।
उदाहरण सारांश:
“signRequest(payload) एक JSON payload लेता है, timestamp और nonce जोड़ता है, फिर method + path + body से HMAC SHA-256 सिग्नेचर बनाता है। यह {headers, body} रिटर्न करता है। त्रुटि तब होती है जब payload में non-ASCII कैरैक्टर्स होते हैं।”
यह आम तौर पर एनकोडिंग, कैनोनिकलाइज़ेशन, और सिग्नेचर मिसमैच का निदान करने के लिए पर्याप्त होता है बिना पूरी इम्प्लीमेंटेशन दिखाए।
अपने प्रॉम्प्ट के अंत में बताएं कि आपने क्या हटाया और क्या रखा। इससे बैक-एंड-फोर्थ कम होता है और अगली बार और सामग्री माँगे जाने की संभावना कम होती है।
उदाहरण:
“Redacted: tokens, emails, customer data, full request bodies. Kept: endpoint paths, status codes, header names, stack trace frames, and the exact error text.”
असिस्टेंट को ऐसे सहकर्मी की तरह ट्रीट करें जिसे केवल वही हिस्सा चाहिए जिस पर आप काम कर रहे हैं। पूरे फाइलों की बजाय इंटरफेसेज़ और कॉन्ट्रैक्ट साझा करें: फ़ंक्शन सिग्नेचर, टाइप्स, रिक्वेस्ट/रेस्पॉन्स शेप्स, और सटीक त्रुटि टेक्स्ट।
सादा भाषा में एक न्यूनतम repro अक्सर पर्याप्त होता है: आपने क्या इनपुट दिया, आपने क्या अपेक्षित किया, क्या हुआ, और कुछ एनवायरनमेंट नोट्स (रनटाइम वर्ज़न, OS, फ्रेमवर्क वर्ज़न)। आपको अपनी पूरी प्रोजेक्ट हिस्ट्री नहीं देनी चाहिए।
अच्छे टेम्प्लेट्स:
सैनिटाइज़्ड कन्फ़िग ब्लॉक एक उपयोगी मध्य मार्ग है। यह दिखाता है कि कौन से नॉब्स हैं बिना सीक्रेट्स के:
# sanitized
DB_HOST: "\u003cset\u003e"
DB_PORT: "5432"
DB_USER: "\u003cset\u003e"
DB_PASSWORD: "\u003credacted\u003e"
JWT_SECRET: "\u003credacted\u003e"
OAUTH_CLIENT_ID: "\u003cset\u003e"
OAUTH_CLIENT_SECRET: "\u003credacted\u003e"
सुरक्षित उदाहरण प्रॉम्प्ट:
“Login fails with 401. Expected 200. Actual response body: ‘invalid token’. Environment: Node 20, local dev, time sync enabled. Request contract: Authorization: Bearer \u003credacted\u003e. Verify steps: token is issued by /auth/login and used on /me. What are the top causes (clock skew, audience mismatch, signing secret mismatch), and what single check confirms each?”
एक भरोसेमंद आदत यह है कि शेयरिंग को एक छोटे रिप्रो के रूप में पैकेज किया जाए। पर्याप्त शेयर करें ताकि समस्या का निदान हो सके, और उससे अधिक कुछ भी नहीं।
एक व्यावहारिक तरीका है एक अस्थायी “शेयर फ़ोल्डर” रखना जो आपके असली रिपो से अलग हो। फाइलों को मैन्युअली वहाँ कॉपी करें न कि पूरा प्रोजेक्ट शेयर करें। यह जानबूझकर विकल्प करने को मजबूर करता है।
वर्कफ़्लो सरल रखें:
फ़ोल्डर बनाकर इसे बाहरी की तरह पढ़ें। अगर कोई फ़ाइल विशेष रूप से बग को डिबग करने में मदद नहीं करती, तो वह वहाँ नहीं होनी चाहिए।
रेडैक्ट करते समय, कोड या लॉग्स को तोड़ने से बचें। मानों को ऐसे प्लेसहोल्डर्स से बदलें जो प्रकार और संरचना रखें। उदाहरण के लिए बदलें:
DATABASE_URL=postgres://user:[email protected]:5432/app
को इस से:
DATABASE_URL=postgres://user:REDACTED@localhost:5432/app
अगर बग किसी थर्ड-पार्टी रिस्पॉन्स पर निर्भर है, तो README में उस रिस्पॉन्स की शेप लिखें और एक सिंथेटिक JSON फ़ाइल शामिल करें जो मिलती-जुलती हो। असली ट्रैफ़िक शेयर किए बिना भी आप अर्थपूर्ण डिबगिंग कर सकते हैं।
एक दोहराने योग्य लूप का उपयोग करें ताकि आप दबाव में इम्प्रोवाइज़ न करें।
पहले दो वाक्य लिखें।
न्यूनतम इनपुट इकट्ठा करें। केवल वह लाएँ जो समस्या को दोहराने या उसके बारे में तर्क करने में मदद करता है: फेलिंग लाइन के आसपास का छोटा स्निपेट, सटीक एरर टेक्स्ट, संबंधित वर्ज़न, और 3–5 repro स्टेप्स।
संरचना को बनाए रखते हुए redact करें। सीक्रेट्स को प्लेसहोल्डर से बदलें और उन पहचानकर्ताओं को हटाएँ जो व्यवहार को प्रभावित नहीं करते (प्रोजेक्ट नाम, टेनेंट IDs, ईमेल)। प्लेसहोल्डर सुसंगत रखें。
API_KEY=sk_live_...
becomes
API_KEY=\u003cAPI_KEY\u003e
customer-1234-prod-db
becomes
\u003cDB_HOST_PROD\u003e
टार्गेटेड सवाल पूछें। "सबसे संभावित कारण क्या हैं?" के साथ "मैं क्या बदलूँ?" जोड़ें। अगर आप पैच चाहते हैं, तो कहें कि बदलाव केवल दिए गए स्निपेट तक सीमित रहे और अनुमान लेबल किए जाएं।
लोकल में सत्यापित करें, फिर एक नया डिटेल जोड़ें। सुझाव को टेस्ट करें। अगर वह काम नहीं करता, तो केवल एक नई चीज़ जोड़ें (अगली स्टैक ट्रेस लाइन, एक कन्फ़िग फ्लैग, या एक संकुचित repro)। सीधे पूरी फ़ाइल पेस्ट न करें।
यह क्रमिक खुलासा आपको वास्तविक उत्तर दिलाने में मदद करता है और सीक्रेट्स व अनरिलेटेड कोड को प्रॉम्प्ट से बाहर रखता है।
एक सामान्य स्थिति: लॉगिन आपके लैपटॉप और स्टेजिंग में काम करता है, पर प्रोडक्शन में फेल होता है। आपको जल्दी मदद चाहिए, पर आप असली टोकन, यूजर ईमेल, आंतरिक होस्टनेम्स या पूरा ऑथ मिडलवेयर पेस्ट नहीं कर सकते।
शुरू करें उन चीज़ों से जो आप ऑब्ज़र्व कर सकते हैं: रिक्वेस्ट/रिस्पॉन्स शेप, स्टेटस कोड, और छोटा स्टैक ट्रेस। अगर JWT-संबंधित है तो आप गैर-संवेदनशील हेडर डिटेल्स (जैसे अपेक्षित एल्गोरिद्म) और टाइमिंग डिटेल्स (सर्वर टाइम ड्रिफ्ट) भी साझा कर सकते हैं। बाकी सब प्लेसहोल्डर रखें।
एक सुरक्षित बंडल अक्सर शामिल होता है:
\u003cJWT_REDACTED\u003e"), और बॉडी फ़ील्ड नाम (कोई असली मान नहीं)फिर एक फोकस्ड सवाल पूछें। प्रोडक्शन-ओनली ऑथ फेल्योर अक्सर क्लॉक स्क्यू, गलत इशूअर/ऑडियंस, अलग साइनिंग कीज़, की रोटेशन मिसिंग, या प्रॉक्सी/हेडर डिफरेंस के कारण होते हैं।
प्रॉम्प्ट पैटर्न:
I have a production-only login/auth failure. Locally it passes.
Observed behavior:
- Endpoint: POST /api/login
- Production response: 401 with message "invalid token" (generic)
- Staging/local: 200
Sanitized request/response:
- Authorization: Bearer \u003cJWT_REDACTED\u003e
- Expected claims: iss=\u003cISSUER_PLACEHOLDER\u003e, aud=\u003cAUDIENCE_PLACEHOLDER\u003e
- Token validation library: \u003cLIB_NAME_AND_VERSION\u003e
Sanitized log snippet:
\u003cPASTE 5-10 LINES WITH TOKENS/EMAILS/HOSTS REDACTED\u003e
Question:
Given this, what are the top causes of JWT validation failing only in production, especially clock skew or claim mismatch? What specific checks and log lines should I add to confirm which one it is?
परिकल्पनाएँ मिलने के बाद, सुरक्षित तरीके से वेरिफाई करें। केवल गैर-संवेदनशील तथ्य (exp, iat, now, और फेल्योर का कारण कोड) लॉग करने वाले टेम्पररी लॉग जोड़ें। एक छोटा टेस्ट लिखें जो एक सुरक्षित टोकन फ़िक्सचर फ़ीड करे और वैलिडेटर बिहेवियर के एज केस पर असर्शन करे।
एक सरल प्लान:
प्राइवेसी लाभ खोने का तेज़ तरीका है "एक छोटी सी चीज़" पेस्ट करना जिसमें चुपके से सब कुछ मौजूद हो। पूरी .env या कन्फ़िग फाइल क्लासिक उदाहरण है। भले ही आप स्पष्ट सीक्रेट हटा दें, ये फाइलें अक्सर आंतरिक होस्टनेम्स, सर्विस नाम और एनवायरनमेंट क्लूज़ छोड़ देती हैं जो आपके सिस्टम का नक्शा बनाते हैं।
फुल स्टैक ट्रेसेस भी अक्सर लीक का कारण बनते हैं। इनमें यूज़रनेम्स, मशीन नेम्स, रेपो नेम्स, और एब्सोल्यूट पाथ्स जैसे /Users/alex/company-payments/... शामिल हो सकते हैं। कभी-कभी वे क्वेरी स्ट्रिंग्स, HTTP हेडर्स, या एरर ऑब्ज़ेक्ट जिनमें टोकन होते हैं, भी दिखा देते हैं। अगर ट्रेस चाहिए, तो केवल संबंधित फ्रेम कॉपी करें और पाथ्स को सुसंगत प्लेसहोल्डर्स से बदल दें।
असली ग्राहक पेलोड भी जोखिम भरे होते हैं भले ही वे "छोटे" हों। एक JSON बॉडी में ईमेल, पते, ऑर्डर IDs, या फ्री-टेक्स्ट नोट्स हो सकते हैं। सुरक्षित कदम यह है कि समान शेप और एज केस वाले नकली पेलोड जेनरेट करें, बिना असली मानों के।
असंगत प्लेसहोल्डर भी परेशानी पैदा करते हैं। अगर USER_ID एक जगह "कस्टमर id" और दूसरी जगह "आंतरिक अकाउंट id" के लिए मतलब रखता है, तो गलत निदान मिलेगा। एक स्कीम चुनें और उस पर टिके रहें।
अगर आपका संदेश किसी अजनबी को लॉगिन करने, आपके सर्वर्स का स्थान पता करने, या किसी ग्राहक की पहचान करने में मदद करेगा, तो उसे फिर से देखें।
जब आप सावधानी बरतने की कोशिश कर रहे हों, तो गति आपका दुश्मन है। एक छोटा रूटीन आपको उपयोगी उत्तर पाने में मदद करता है जबकि संवेदनशील डेटा बाहर रहता है।
एक पास सीक्रेट्स के लिए और दूसरा पहचानकर्ताओं के लिए:
रेडैक्ट करने के बाद, संरचना रखें। प्रकार, स्कीमा, फ़ील्ड नाम, स्टेटस कोड और उदाहरण पेलोड संरचना छोड़ दें, पर असली मानों की जगह प्लेसहोल्डर रखें।
दबाव में एक ही नियम दोहराने के लिए, कुछ रेडैक्शन रूल्स लिखें और इन्हें फिर से उपयोग करें। टीम्स के लिए, इसे एक साझा टेम्पलेट बनाएं जिसमें दो ब्लॉक्स हों: "मैं क्या साझा कर रहा हूँ" (फाइलें, फ़ंक्शन, एंडपॉइंट) और "मैं क्या नहीं साझा कर रहा हूँ" (सीक्रेट्स, प्रोडक्शन डेटा, आंतरिक डोमेन्स)।
अगर आप एक अतिरिक्त सुरक्षा परत चाहते हैं, तो अपने प्रयोग किसी अलग-थलग एनवायरनमेंट में करें और बदलाव reversible रखें। Koder.ai (koder.ai) में, प्लानिंग मोड आपकी मदद कर सकता है यह बताने में कि परीक्षण करने के लिए सबसे छोटा बदलाव क्या है, और स्नैपशॉट्स व रॉलबैक आपको बिना अतिरिक्त संवेदनशील संदर्भ के समाधान आजमाने में आसान बनाते हैं।
एक छोटे से हिस्से से शुरू करें जो आपके सवाल का जवाब दे सके: फेल होने वाला इनपुट, अपेक्षित बनाम वास्तविक आउटपुट, और उस संकुचित कोड पाथ से जुड़ी फाइलें।
एक अच्छा डिफ़ॉल्ट बंडल है:
नहीं पेस्ट करें:
.env/कन्फ़िग फाइलें या कच्चे प्रोडक्शन लॉगअगर किसी अजनबी को इससे लॉगिन करने, किसी व्यक्ति की पहचान करने, या आपके सिस्टम का नक्शा बनाने में मदद मिलती है, तो उसे redact या summarize करें।
फ़्लो पढ़ने में आसान रखने के लिए सुसंगत प्लेसहोल्डर का इस्तेमाल करें।
उदाहरण स्कीम:
TOKEN_1, TOKEN_2API_KEY_1USER_ID_1, जब बग पार्सिंग या वैलिडेशन पर निर्भर हो, तब फॉर्मैट बनाए रखें।
सामान्य केस:
8-4-4-4-12 पैटर्न रखेंयह असली मान को एक्सपोज़ किए बिना व्यवहार को वास्तविक रखता है।
फ़ील्ड नाम, नेस्टिंग और प्रकार रखें; मान बदलें।
JSON के लिए:
SQL के लिए:
उदाहरण:
इन्पुट/आउटपुट और उस विशेष नियम को बताकर सारांश दें जो बग को प्रभावित कर रहा है।
एक व्यावहारिक सारांश में शामिल हो:
अक्सर इससे वही डीबगिंग वैल्यू मिल जाती है बिना आपकी इम्प्लीमेंटेशन दिखाए।
एक साधारण सुरक्षित प्रॉम्प्ट ऐसा दिखता है:
एक रेडैक्शन नोट भी जोड़ें जैसे:
"Redacted: tokens, emails, customer data, internal hostnames. Kept: endpoint paths, status codes, header names, exact error text."
क्योंकि वे अक्सर सब कुछ एक साथ रखती हैं:
एक सुरक्षित विकल्प है कन्फ़िग टेम्पलेट:
इंक्रिमेंटल डिस्क्लोज़र का उपयोग करें:
यह स्कोप को छोटा रखता है और दबाव में अनजाने रिस्क से बचाता है।
एक व्यावहारिक बंडल है:
फिर पूछें:
CUSTOMER_ID_1EMAIL_1ज़रूरत पड़ने पर छोटा लेजेंड जोड़ें:
TOKEN_1: /me पर उपयोग किया गया Authorization bearer tokenCUSTOMER_ID_1: डेटाबेस लुकअप में उपयोग की जाने वाली पहचानकर्ताWHERE user_id = USER_ID_1 AND created_at > DATE_1\u003cset\u003e या \u003credacted\u003e से बदलें