रजिस्ट्री क्या है
FlareWatch के इतिहास में बग का प्रत्येक आवर्ती वर्ग एक क्रमांकित सुरक्षा उपाय में विभाजित किया गया है: एक पैराग्राफ का नियम, एक औचित्य, और कोड में उस स्थान का एक सूचक जो इसे लागू करता है। नए सुरक्षा उपाय तब जोड़े जाते हैं जब बग या पैटर्न का एक वर्ग उभरता है जिसे दोहराए जाने से रोका जाना चाहिए।
रजिस्ट्री एक कार्यशील दस्तावेज है, विपणन प्रतिलिपि नहीं। इसका उद्देश्य टीम को — और ऑडिट-पहली समीक्षा लूप को जो टीम उपयोग करती है — यह जानने के लिए ईमानदार रखना है कि कौन से नियम कहां लागू होते हैं। रजिस्ट्री को इनलाइन कोड टिप्पणियों (उदाहरण के लिए, // सुरक्षा उपाय 24) से संदर्भित किया जाता है ताकि किसी भी व्यक्तिगत फ़ाइल का पाठक उस नियम को ढूंढ सकता है जो आसपास की पंक्तियों को नियंत्रित करता है।
यह पृष्ठ सार्वजनिक सारांश है। पूरी रजिस्ट्री स्रोत भंडार में उस कोड के साथ रहती है जिसे वह नियंत्रित करता है। यहां का उद्देश्य एक सुरक्षा शोधकर्ता, अनुदान समीक्षक, या संभावित योगदानकर्ता को रजिस्ट्री जो श्रेणियां कवर करती है और जिस अनुशासन को वह लागू करती है उसका एक विचार देना है।
रजिस्ट्री क्यों
एक सेफगार्ड रजिस्ट्री केवल तभी अपना काम करती है जब वह एक ही बग को दो बार रोके। रजिस्ट्री का ट्रैक रिकॉर्ड उत्तर है:
- प्रत्येक सेफगार्ड उस बग का नाम बताता है जिसे वह रोकता है। बिना किसी याद किए गए घटना के पीछे का नियम एक सेफगार्ड नहीं है, यह एक शैली की पसंद है। शैली की पसंद लिंट नियमों में रहनी चाहिए, रजिस्ट्री में नहीं।
- सेफगार्ड्स को कोड से संदर्भित किया जाता है, केवल दस्तावेज़ से नहीं। एक कोड परिवर्तन जो एक सेफगार्ड का उल्लंघन करता है, समीक्षा के समय एक झंडे के रूप में पढ़ा जाता है क्योंकि सेफगार्ड संख्या आसपास की टिप्पणियों में होती है।
- कुछ सेफगार्ड्स स्वचालित रूप से लागू होते हैं। एक उप-समूह ESLint नियमों या शेल स्क्रिप्ट के माध्यम से लागू किया जाता है जो CI में चलते हैं। बाकी लेखक अनुशासन और ऑडिट-पहली समीक्षा पैटर्न पर निर्भर करते हैं, जो व्यवहार में अच्छी तरह से काम कर रहे हैं।
- रजिस्ट्री को परीक्षणों द्वारा सच रखा जाता है। कई सेफगार्ड्स प्रतिगमन परीक्षणों द्वारा पिन किए जाते हैं जो स्रोत फ़ाइलों को स्ट्रिंग के रूप में पढ़ते हैं और दावा करते हैं कि एंटी-पैटर्न प्रकट नहीं होते हैं। भंगुरता विशेषता है: एक भविष्य का रीफैक्टर जो एक एंटी-पैटर्न में वापस आता है, परीक्षा विफल कर देता है उससे पहले कि प्रतिगमन उत्पादन तक पहुंचे।
श्रेणियां
रजिस्ट्री को डोमेन द्वारा संगठित किया जाता है। नीचे दी गई श्रेणियां स्थिर हैं; प्रत्येक के भीतर विशिष्ट सेफगार्ड्स नई विफलता के तरीके खोजे जाने पर जोड़े जाते हैं।
| श्रेणी | यह क्या कवर करता है |
|---|---|
| प्रमाणीकरण और प्राधिकरण | सत्र सत्यापन के लिए एकल नियंत्रण बिंदु, हर रूट पर प्रति-वॉलेट स्वामित्व जांच, एक्सेस और रीफ्रेश टोकन के बीच क्रॉस-टोकन अस्वीकृति, प्रशासक-रूट गेटिंग। |
| डेटा अखंडता | पता सामान्यीकरण, निर्माता/उपभोक्ता सीमाओं पर यूनिट-रूपांतरण अनुबंध, कुंजी-बिल्डर अनुशासन, और विफलताओं को मौन रूप से शून्य मानों में विलय करने के विरुद्ध नियम। |
| ऑन-चेन रीड्स | स्मार्ट कॉन्ट्रैक्ट से पढ़े गए किसी भी मान के लिए एकल-कार्यान्वयन नियम, ऑन-चेन रजिस्ट्री से अनुबंध पता संकल्प, और पुरस्कार तर्क को दोहराने के विरुद्ध नियम। |
| प्रदर्शन की शुद्धता | केंद्रीकृत संख्या, मुद्रा और तारीख स्वरूपण; हर संख्यात्मक प्रदर्शन पर शून्य-सुरक्षा; APR बनाम APY लेबलिंग अनुशासन; कर-दर-के-रूप में-प्रभावी अनुशासन। |
| सतर्कताएं और सूचनाएं | अलर्ट मूल्यांकन के लिए क्लाइंट और सर्वर में एकल सत्य स्रोत; स्पष्ट अनुमति सूचियाँ कि कौन से अलर्ट देखे गए वॉलेट तक पहुंचते हैं; सुपरसेशन नियम जो एक "rewards landed" अलर्ट को एक स्टेल "rewards available" अलर्ट को रद्द करता है; क्रॉस-डिवाइस dismiss सिंक्रोनाइजेशन। |
| Persistence और कैश | कब कैनोनिकल स्टोर key-value बैकेंड बनाम localStorage है इसके लिए नियम; माइग्रेशन अनुशासन; deploy-scoped service worker कैश; ऐसे मार्गों के लिए स्पष्ट गतिशील opt-out जो live state पढ़ते हैं। |
| UI और lifecycle | Page-readiness गेट्स, monotonic फर्श जो transient zeros को ज्ञात शेषराशि से विस्थापित होने से रोकते हैं, और cold-fetch विंडो के दौरान skeleton-rendering के लिए नियम। |
| Process और tooling | स्पष्ट feature-launch सहमति के लिए नियम, alert-surface परिवर्तनों पर पूर्ण-suite परीक्षा चलाता है, server-side कोड में structured लॉगिंग, और shortcut-style fixes के विरुद्ध समीक्षा अनुशासन। |
कुछ प्रतिनिधि नियम
ये सार्वजनिक-सुरक्षित सारांश हैं जो रजिस्ट्री के चरित्र को दर्शाते हैं। ये paraphrased और संक्षिप्त हैं; कैनोनिकल पाठ कोड के आगे है।
On-chain reads के लिए सत्य का एकल स्रोत
स्मार्ट कॉन्ट्रैक्ट से पढ़ा गया कोई भी value — claimable rewards, balances, stake state, epoch data, prices — services layer में बिल्कुल एक फ़ंक्शन द्वारा computed होता है। हर फीचर जिसे उस value की जरूरत है वही फ़ंक्शन import करता है। यदि दो फ़ंक्शन समान value compute करते हैं, तो उनमें से एक गलत है; नियम इसे delete करना है, तीसरा नहीं जोड़ना है।
Session validation के लिए एकल choke point
FlareWatch में हर authenticated route एकल helper के माध्यम से session cookies को validate करता है। कोई भी route handler independently session tokens को verify नहीं करता है। यह invariant वह है जो server-side revocation को universal बनाता है — कोई side door नहीं जो check को bypass करता है।
Per-wallet ownership gating, दोनों sides
Per-wallet routes server-side पर ownership verify करते हैं, client-side पर नहीं। मूल audit ने यह नियम स्थापित किया क्योंकि पहले के काम ने client-side gates को बंद कर दिया था लेकिन server-side endpoints को पूरी तरह ungated छोड़ दिया था। दोनों halves को अब अलग-अलग explicit deliverables के रूप में tracked किया जाता है — client पर बंद, server पर बंद — ताकि यह failure mode दोबारा न हो।
केंद्रीकृत फॉर्मेटर्स का उपयोग करें, कभी भी इनलाइन नहीं
सभी संख्या, मुद्रा, और दिनांक फॉर्मेटिंग केंद्रीकृत सहायकों के एक छोटे सेट के माध्यम से जाती है। कोई भी घटक इनलाइन फॉर्मेट नहीं करता है। नियम का शैली से कोई संबंध नहीं है: जब एक एकल लोकेल या मुद्रा परिभाषा बदलती है, तो एप्लिकेशन में हर सतह इसके साथ अपडेट होती है। सतहों के बीच विचलन मूक है और तब तक पकड़ में आना कठिन है जब तक कोई उपयोगकर्ता इसे नोटिस न करे।
इकाई रूपांतरण दोनों सिरों पर दस्तावेज़ित हैं
जब सिस्टम के दो भाग मानों का आदान-प्रदान करते हैं जिनकी इकाई अस्पष्ट हो सकती है (सेकंड बनाम मिलीसेकंड, दशमलव बनाम प्रतिशत, निचले-केस बनाम चेकसमड पते), सम्मेलन उत्पादक और उपभोक्ता दोनों पर दस्तावेज़ित है। केवल एक सिरे पर टिप्पणी सड़ जाती है; केवल एक सीमा अनुबंध जो दोनों सिरों पर पुष्ट हो, रीफ़ैक्टर को सहन करता है।
प्रति उपयोगकर्ता क्रिया एक कार्यान्वयन
हर उपयोगकर्ता-शुरू की गई क्रिया — देखे जाने वाले वॉलेट जोड़ना, कर दर बदलना, सतर्कता को खारिज करना, साइन आउट करना — का बिल्कुल एक कार्यान्वयन है। नियम इसलिए मौजूद है क्योंकि UI के विभिन्न भागों से ट्रिगर की गई क्रियाएं सूक्ष्म तरीकों से विचलित होती थीं: एक प्रवेश बिंदु कैश को साफ़ करेगा, दूसरा नहीं करेगा, और "ऑपरेशन X के बाद स्टेल मान" बग की एक कक्षा परिणाम होगी।
विफलता के तरीके जो जोर से होने चाहिए
कुछ विफलता के तरीके प्रकृति से मूक हैं — गलत तरीके से वर्गीकृत पुरस्कार, एक इकाई असंगति जो किसी सूचना को नो-ऑप में बदल देती है, एक खारिज रिकॉर्ड जो कभी भी कुंजी-मूल्य स्टोर तक नहीं पहुंचता है। जहां संभव हो, रजिस्ट्री की आवश्यकता है कि इन मानों के उत्पादक अपने अनुबंध को काफी जोर से घोषित करें कि एक भविष्य का परिवर्तन जो इसका उल्लंघन करता है, परीक्षणों में शोर-शराबे से विफल हो, उत्पादन तक पहुंचने से पहले।
रजिस्ट्री कैसे विकसित होती है
- नई सुरक्षा उपाय। जब बग की एक कक्षा दोहराई जाती है या एक एकल बग पर्याप्त खर्च होता है तो एक स्थायी नियम को न्यायसंगत ठहराता है।
- अतिक्रमित सुरक्षा उपाय। रजिस्ट्री में रखा जाता है जिसमें "अतिक्रमित" मार्कर और प्रतिस्थापन के लिए एक सूचक होता है, ताकि कोड में ऐतिहासिक संदर्भ व्याख्या योग्य रहें।
- कार्यकारी नोट्स से पदोन्नत। कुछ सुरक्षा उपाय सत्र हस्तांतरण दस्तावेज़ में अनौपचारिक नियमों के रूप में शुरू होते हैं और एक बार जब वे अपना वजन साबित करते हैं तो रजिस्ट्री में पदोन्नत किए जाते हैं।
- त्रैमासिक समीक्षा। अस्थायी lint अपवाद और "अगली तिमाही तक टू-डू" मार्कर एक त्रैमासिक गति पर जांचे जाते हैं। कोई भी चीज़ जो उम्र बढ़ गई है उसे या तो समाधान किया जाता है या स्पष्ट रूप से बढ़ाया जाता है।
यह क्यों प्रकाशित किया गया है
FlareWatch इस अवलोकन को प्रकाशित करता है, पूर्ण आंतरिक रजिस्ट्री के बजाय, दो कारणों से।
- आंतरिक रजिस्ट्री में कोड-स्तरीय विवरण (फ़ाइल पथ, कुंजी-मान स्कीमा नाम, घटना टाइमस्टैम्प) होता है जो टीम और कोड एक्सेस वाले सुरक्षा समीक्षक के लिए उपयोगी है, लेकिन उस एक्सेस के बिना प्रकाशित करने के लिए उपयुक्त नहीं है।
- श्रेणियां और अनुशासन वास्तविक कहानी हैं। एक अनुदान समीक्षक या सुरक्षा शोधकर्ता जो FlareWatch का मूल्यांकन कर रहा है, वह जानना चाहता है कि यह किस प्रकार की परियोजना है, यह शुद्धता को कितनी गंभीरता से लेता है, और इसका कार्य लूप कैसा दिखता है — यह नहीं कि कौन सी फ़ाइल नियम #91 को रखती है।
शोधकर्ता जो किसी विशिष्ट सुरक्षा उपाय पर चर्चा करना चाहते हैं, एक नया प्रस्तावित करना चाहते हैं, या कोई अंतराल रिपोर्ट करना चाहते हैं, [email protected] पर संपर्क करने के लिए आमंत्रित हैं.
अतिरिक्त पढ़ें
- आर्किटेक्चर — FlareWatch कैसे बनाया गया है।
- सुरक्षा सुविधाएँ — प्रमाणीकरण, प्राधिकरण, हेडर, ऑडिट इतिहास।