एक छोटी विरासत कोड अध्ययन की कहानी

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

यह उस समय हुआ, जब मुझे ऐसा लग रहा था, विकास में औसत दर्जे का अनुभव, मैं एक ऐसी जगह की तलाश में था, जहाँ आप एक गैर-जूनियर से लेकर एक आश्वस्त जूनियर तक भी विकसित (या म्यूट) हो सकते हैं। भगवान के रहस्यमय तरीकों से, ऐसी जगह मिल गई, एक परियोजना जगह से जुड़ी हुई थी, और "पुराने-स्कूल" प्रोग्रामर, जिन्होंने सिस्टम में अपने कैरियर से अधिक लड़कियों को लिखा था। "बहुत बढ़िया! परियोजना, और इसलिए आरएफपी के लिए पैसा है, संरक्षक संलग्न है, हम रहते हैं! " मैंने सोचा, लेकिन फिर, जैसा कि एक विशिष्ट हॉरर के विवरण में है, अंधेरे में नायकों ने भयानक आतंक का सामना किया ...

पहली चीजें पहले:

1. आकार मायने रखता है

हमने डेटा को स्टोर करने के लिए उपयोग किए जाने वाले एक बार-स्वामित्व वाले php इंजन पर विकास शुरू किया था (यहां आप सोच सकते हैं कि MySQL \ PostgreSQL \ SQLite \ MongoDB \ कुछ और-लेकिन-जरूरी-साथ-प्रत्यय DB-अन्यथा- लोग-नहीं समझते, लेकिन उन्होंने अनुमान नहीं लगाया) एपी-गेटवे।

"हा, php का उपयोग करते हुए, क्या आप इसके लिए एक और एपि-गेटवे संलग्न करते हैं, और उस पर डेटा स्टोर करते हैं? क्या js-code से सीधे api के साथ काम करना आसान नहीं है? या DBMS + PHP का उपयोग करें? - अनुभवी पाठक से पूछें। और वह सही हो जाएगा। लेकिन उस समय, मैं, जिसने अभी तक प्रजातियों को नहीं देखा था, उसने ऐसा नहीं सोचा था, ठीक है, जो जानता है, शांत लोग शायद ऐसा करते हैं, और "पुराने-स्कूल" प्रोग्रामर बेहतर जानते हैं।

जैसा कि मुझे आगे समझाया गया था:

1. गेटवे = सुरक्षा, कोई भी प्रवेश नहीं करेगा और उसी तरह बाहर निकलेगा
2. गेटवे = सुरक्षित डेटा संग्रहण, आप बस इसमें नहीं जा सकते, + बैकअप
3. गेटवे = गति, तेजी से और बिना असफलताओं के, समय-परीक्षण के साथ काम करता है
4. "ओल्ड-स्कूल" प्रोग्रामर्स के आधिकारिक दृष्टिकोण यह है कि आपका php छेदों से भरा है, किसी भी वेब एप्लिकेशन को डिफ़ॉल्ट रूप से हैक किया जाता है, इसलिए इसके आगे डेटा स्टोर करने के लिए कुछ भी नहीं है

एपीआई गेटवे की एक विशेषता यह थी कि एक अनुरोध प्राप्त करने में जोंस डेटा प्रसारित किया गया था। हां, हां, उन बहुत ही प्यारे जोंस-ऑब्जेक्ट्स को यूआरएल-एन्कोडिंग के अधीन किया गया था, और क्वेरी स्ट्रिंग में डाल दिया गया था। और सब कुछ ठीक हो जाएगा, जब अचानक एक दिन ... प्राप्त अनुरोध की लंबाई पर्याप्त हो गई। Stupidly, url- एन्कोडेड जोंस, कनैल्या वहाँ फिट नहीं था! "पुराने स्कूल" प्रोग्रामर ने अपना सिर खुजलाते हुए पूछा:
“हम क्या करने जा रहे हैं? हमारा जसन बड़ा हो गया है, लेकिन हमने ध्यान नहीं दिया ... "
"ठीक है, उह, शायद तब हम उन्हें पोस्ट में पोस्ट करेंगे?" मैंने सुझाव दिया, इसलिए यह अधिक सही प्रतीत होता है।
"ठीक है, पोस्ट करने के लिए पास।"
यह अतास नंबर एक था।

2. समय और बैकअप प्रबंधन

परियोजना में नई कार्यक्षमता को पेंच करने के लिए, इसे लागू करना आवश्यक था
गेटवे पर संगत CRUD अनुरोध, जो वास्तव में हमारे "पुराने स्कूल" कॉमरेड ने किया था। समस्या यह थी कि उसने हर 3 दिन में एक बार ऐसा किया, "जाँच किया।" कई बार चेक से पता चला कि सब कुछ काम नहीं किया गया है, उदाहरण के लिए, सूची प्राप्त करना ठीक है, एक नया आइटम जोड़ना ठीक नहीं है। इसे ठीक करने और परिष्कृत करने के लिए कुछ समय लगा, जिसके बाद मास एक्सेस में कार्यक्षमता को जारी करना संभव हो गया। स्वयं गेटवे पर प्रश्नों के कार्यान्वयन में संलग्न होने का प्रस्ताव, क्योंकि यह कम से कम तेज़ है, अस्वीकार कर दिया गया था, क्योंकि "यह वहाँ मुश्किल है, आप समझ नहीं पाएंगे।" इस दृष्टिकोण का परिणाम "खुद पर" काम बंद करना था। यदि, उदाहरण के लिए, डेटाबेस में कुछ एन मसाज को ठीक करना आवश्यक था, तो, 3-दिवसीय प्रतीक्षा और प्रश्नों के माध्यम से स्वयं सुधारों के कार्यान्वयन के बीच चयन करना - मैंने दूसरा विकल्प चुना। ग्राहक विशेष रूप से इंतजार करना पसंद नहीं करते थे, नए परिचयात्मक रूप से उड़ान भरी। ऐसे परिचयात्मक लोगों में से एक, अर्थात् कुछ संकेत के उपयोगकर्ताओं के लिए एक हस्ताक्षर का द्रव्यमान, मुझे लागू करने के लिए सौंपा गया था, सब कुछ के बारे में सब कुछ के लिए एक घंटे था, अधिकारी एक सुंदर रिपोर्ट की प्रतीक्षा कर रहे थे। यहां हमें अतास नंबर दो-एस का इंतजार है।

तथ्य यह है कि अनुरोधों में प्रेषित जोंस डेटा का प्रारूप केवल कुछ आवश्यक क्षेत्रों में निहित है, अन्य सभी मनमाना थे, एक स्पष्ट और अंतिम संरचना मौजूद नहीं थी। उदाहरण के लिए, उपयोगकर्ता को जोड़ने के लिए, मैंने फॉर्म का एक json पास किया:

POST /api/users { "email":"ivanov@mail.ru", "password":"myEmailIsVeryBig", "name_last":"", "name_first":"", "name_middle":"", "birth":"01.01.1961", //     ,    -    "living_at":"., .3 .4 .24", "phone_num":"+70000000000" } 

ऐड / अपडेट रिक्वेस्ट में ट्रांसमिट किए गए ऑप्शनल पार्ट को पूरी तरह से सेव कर दिया गया था (मैं इसके बारे में बताऊंगा कि इसे नीचे कैसे लागू किया गया था)। लब्बोलुआब यह है, समय अभी भी खड़ा नहीं है, समस्या को हल करने के लिए आवश्यक होगा - उपयोगकर्ताओं को अपडेट करने के लिए, उनके लेबल नीचे रखें। लेकिन हर बार पूरी संरचना को ड्राइव नहीं करते हैं? जाँच करनी चाहिए! मैंने इसे अपने आप पर परीक्षण किया - मैंने अपडेट अनुरोध में केवल एक फ़ील्ड संचारित किया, जाँच की, फ़ील्ड दिखाई दी, बाकी डेटा जगह में है। बिंदु छोटा है - लूप और बाकी को अपडेट करें।

स्क्रिप्ट ने धीरे से पफ किया, डेटा प्राप्त करना और प्रसारित करना, और सब कुछ ठीक लग रहा था ... जब अचानक - एक कॉल। "हम सिस्टम में उपयोगकर्ताओं का नाम नहीं देखते हैं!" - तार के उस छोर से रिपोर्ट। “चलो! खैर यह काम किया! ” - मेरी पीठ पर एक अप्रिय सर्द दौड़ गई। आगे की जांच से पता चला कि वास्तव में, नाम "" नाम में इंगित किया गया था, हालांकि अन्य सभी डेटा जगह में थे। ऐसी स्थिति में क्या करें? बैकअप तैनात करें!

"कॉमरेड" पुराने स्कूल "प्रोग्रामर, वाई हेव एर समस्याओं हिर! बैकअप चाहिए! नवीनतम प्रासंगिक कब किया जाता है? ” - मैं पूछता हूं।

“उह… अब मैं देखूंगा…। नहीं, वहाँ कोई बाकापा नहीं है। ”

स्थिति को इस तथ्य से बचाया गया था कि कुछ घंटे पहले मैंने अंतिम रूप दिया और रिपोर्ट के साथ मॉड्यूल का परीक्षण किया, मेरे पास सभी आवश्यक डेटा के साथ एक सीएसवी-बॉक्स था, आदेश एक और घंटे के भीतर बहाल किया गया था।

समझदार प्रलेखन की कमी, कार्य एल्गोरिदम का वर्णन, इनपुट वैधता की जाँच, और सबसे महत्वपूर्ण बात - डेटाबेस बैकअप - अतास नंबर दो-एस।

तब से, बैकअप हर दिन हटाया जाने लगा।

3. गहरा प्रहार

अस्थिर, लेकिन काम चल रहा था, समस्याओं को हल किया गया था, कुछ तेज, कुछ धीमी, जब अचानक ... ग्राहकों ने महसूस किया कि सिस्टम को किसी और के सर्वर द्वारा नहीं समझा गया था, और पीडी के प्रति इस तरह के रवैये और आईएसपीडी में जेडआई गतिविधियों के आयोजन के लिए वे सिर नहीं हिलाएंगे। सर्वर को अपने आप में स्थानांतरित करना आवश्यक है।

मूल रूप से तबादला क्यों नहीं किया गया? नेतृत्व का एक जुनून था - केंद्रीकरण। प्रबंधन ने एक ऐसी प्रणाली का सपना देखा जो सब कुछ करेगा! क्या आपको स्कूल में एक बच्चे को संलग्न करने की आवश्यकता है? आप सिस्टम में जाते हैं, एक विशेष कार्यालय में, आप एक आवेदन जमा करते हैं। आपको पिज्जा ऑर्डर करने की आवश्यकता है - आप सिस्टम में जाते हैं, एक अन्य विशेष कार्यालय में, पिज्जा के लिए आवेदन करते हैं। शायद आप सुंदर महिलाओं / सज्जनों के साथ संवाद करना चाहते थे? आपकी सेवा में एक तीसरा विशेष कैबिनेट है - आप वहां एक आवेदन भी जमा कर रहे हैं।

लाभ - सब कुछ के लिए एक लॉगिन और पासवर्ड, डेटा गेटवे पर सुरक्षित और सुरक्षित रूप से संग्रहीत है। यहां तक ​​कि बैकअप भी हैं। और, तुम मन करो, कोई भी इस प्रणाली को हमसे नहीं लेगा! और भले ही वह इसे दूर ले जाए - आगे क्या है? सभी समान, वे "पुराने-स्कूल" प्रोग्रामर के खिलाफ सुरक्षा की प्रणाली को नहीं समझते हैं - वहां सब कुछ जटिल है।

सिस्टम के साथ VDS अनलोड किया गया था, ग्राहकों को जिम्मेदार ठहराया, उन्होंने इसे तैनात किया, हर कोई नृत्य करता है और गाता है, सौंदर्य!

और फिर जिज्ञासा की लहर और कुछ संदेह ने मुझे ढक लिया।

यदि हमारा वेब एप्लिकेशन छिद्रों से भरा है, तो डेटा कहां है? क्या आप वास्तव में अन्य सर्वर पर बने हुए हैं? और अगर वे बाहर से सिस्टम को बंद करने का फैसला करते हैं, तो सब कुछ ढह जाएगा?

एक साधारण जांच से पता चला कि डेटा, साथ ही गेटवे प्रोसेसर खुद एक ही सर्वर पर थे। और, नहीं, वे सर्वर के हस्तांतरण के कारण वहां स्थानांतरित नहीं हुए थे, वे हमेशा वहां थे।
अब मेरे पास उस निपटान में बहुत ही गुप्त "पुराने स्कूल" का विकास था, जो मैंने शोध के बारे में निर्धारित किया था। बेशक, हैकर पत्रिका के लेखों की शैली में कूल रिवर्स इंजीनियरिंग, ओलीडबग, ऑफ़सेट और अन्य ठंडी चीजों के साथ काम नहीं किया, इसलिए मेरे पास जो है उसे साझा कर रहा हूं।
विकास को अजगर में ही लागू किया गया था, केवल .pyc फाइलें थीं जिन्हें आसानी से पठनीय कोड में वापस विघटित किया जा सकता था। सच कहूँ तो, यह पता लगाने में 25 मिनट, जितना काम करता है, उतना समय लग गया।

तो, "पुराने स्कूल" प्रोग्रामर द्वारा विकसित जटिल प्रणाली, जिसे कुछ ही समझ सकते हैं, में शामिल हैं:

1. अपाचे द्वारा संसाधित स्क्रिप्ट, जिसे वास्तव में अनुरोध प्राप्त हुआ। इस स्क्रिप्ट ने क्या किया? एक विशिष्ट लोकलहोस्ट पोर्ट के लिए एक कनेक्शन खोला और अपने सभी डेटा के साथ एक अनुरोध पारित किया। वह सब है। रुचियाँ आगे बढ़ती हैं।
2. सर्वर भाग जो स्क्रिप्ट से अनुरोधों को संसाधित करता है। उनके कार्यों का तर्क काफी दिलचस्प था। सबसे पहले, कोड में कोई डेटा हेरफेर नहीं था, और डेटाबेस में कोई प्रश्न नहीं था, इसके बजाय, पीएल \ एसक्यूएल में डेटाबेस फ़ंक्शन को बुलाया गया था। डेटाबेस फ़ंक्शन में सभी तर्क, जांच और इतने पर सब कुछ निर्धारित किया गया था। स्क्रिप्ट का 50% एक शब्दकोश था जिसमें अनुरोध, उसके साथ जुड़े फ़ंक्शन और फ़ंक्शन के मापदंडों के नाम शामिल थे जो कि गेट-रिक्वेस्ट लाइन में पारित डेटा के अनुरूप होना चाहिए। JSON डेटा, यदि आवश्यक हो, एक अलग पैरामीटर के रूप में पारित किया गया था। सर्वर भाग के संगठन की एक विशेषता उपयोगकर्ता प्रमाणीकरण के दौरान बैकअप कनेक्शन थी। यदि डेटाबेस में लॉगिन और पासवर्ड पाए गए थे, तो सत्र आईडी उत्पन्न हो गई थी, और खुले कनेक्शन का उदाहरण डिक्शनरी में बदल गया था (और 10 मिनट के समय से मार दिया गया था ताकि यह मारा न जाए - सत्र के जीवन का विस्तार करने के लिए एक विशेष विधि थी), कुंजी सत्र आईडी थी, जो सीधे डेटाबेस में है संग्रहित नहीं है। सत्र आईडी उपयोगकर्ता डेटा के साथ कैसे संबद्ध है? आखिरकार, क्या डेटा के लिए एक अनुरोध है जिसमें उपयोगकर्ता आईडी प्रसारित नहीं है? यह काम करता है, जिसका मतलब है कि यहां कुछ गलत है।

चेतना के साथ बहुत मुश्किल विकास दिया गया था और अतीत के आकाओं के लंबे-खोए रहस्यों को उजागर करने की कोई जल्दी नहीं थी।

अतुल्य (जाओ> परिभाषा, पीएल \ एसक्यूएल को समझने के लिए धन्यवाद PhpStorm), पुराने स्कूल प्रोग्रामरों की खोई हुई सभ्यता के सच्चे ज्ञान पीड़ित पीड़ित के दिमाग के लिए समझ से बाहर था। सामान्य तौर पर, कनेक्ट होने पर, प्रमाणीकरण डेटा सत्यापन फ़ंक्शन में एक अस्थायी तालिका बनाई गई थी, जिसमें उपयोगकर्ता आईडी संग्रहीत की गई थी।

यह सिर्फ शुरुआत थी, गंभीर कमजोरियों की एक सांकेतिक सूची मिली:

• सामूहिक प्रमाणीकरण का उपयोग कर DDoS (कनेक्शन आरक्षित थे, और, इसलिए, DBMS की कनेक्शन सीमा पर आराम किया, जिसने सत्र जीवन के समय को बढ़ाने की संभावना को देखते हुए, कनेक्शन के साथ मेमोरी को पूरी तरह से भरना संभव बना दिया, और सिस्टम में नए उपयोगकर्ताओं का काम असंभव होगा);
• ब्रूट फोर्स के खिलाफ सुरक्षा की कमी (असफल लॉगिन प्रयासों की संख्या का पता नहीं लगाया गया है, संग्रहीत नहीं है, चेक नहीं किया गया है;
• संस्थाओं के साथ कार्यों पर नियंत्रण की कमी (उदाहरण के लिए, उपयोगकर्ता द्वारा अनुरोध किए गए दस्तावेज़ों की सूची उस संगठन को ध्यान में रखते हुए जारी की गई थी जिसमें उपयोगकर्ता संलग्न है, और यदि आपको दस्तावेज़ की आईडी पता है, तो आप दस्तावेज़ को अद्यतन / हटाने के अनुरोध को सफलतापूर्वक पूरा कर सकते हैं, और उपयोगकर्ताओं की सूची भी बिना अच्छी है पासवर्ड, जो संयोगवश, डेटाबेस में बिना हैशिंग के, स्टोर किए गए थे, किसी को भी प्राप्त हो सकते हैं)।

और एक और गंभीर समस्या एक औपचारिक डेटा संग्रहण योजना नहीं है। जैसा कि पहले वादा किया गया था, मैं JSON से "किसी भी फ़ील्ड" को संग्रहीत करने के बारे में बात कर रहा हूं। नहीं, उन्हें तालिका में एक पंक्ति के रूप में संग्रहीत नहीं किया गया था। उन्हें कुंजी-मूल्य जोड़े में विभाजित किया गया था और एक अलग तालिका में संग्रहीत किया गया था। उदाहरण के लिए, उपयोगकर्ताओं के लिए 2 टेबल थे - उपयोगकर्ता, और users_data (स्ट्रिंग कुंजी, स्ट्रिंग मूल्य) - जहां डेटा वास्तव में संग्रहीत किया गया था। इस दृष्टिकोण का परिणाम डेटाबेस से जटिल नमूनों के साथ समय में वृद्धि थी।

वास्तव में यह सिस्टम को एक नई एपीआई, समझने योग्य, प्रलेखित, और समर्थित को स्थानांतरित करने के निर्णय को लागू करने के लिए पर्याप्त था।

नैतिकता

शायद यह प्रणाली "लिगेसी" है, और "ओल्ड-स्कूल" प्रोग्रामर जिसने इसे बनाया है वह लिगेसी का सार है।

फिर भी, निष्कर्ष इस प्रकार हैं:

1. यदि आपको बताया जाता है कि "यह कठिन है, तो आप समझ नहीं पाए" - इसका मतलब है कि एक पूर्ण अता है
2. यदि उन्हें अधिकार से कुचल दिया जाता है, तो कुछ अशुद्ध है
3. विश्वास करें, लेकिन सत्यापित करें - सुरक्षा एक राज्य नहीं है, सुरक्षा एक प्रक्रिया है, इसके अलावा निरंतर है, इसलिए यह सुनिश्चित करना बेहतर है कि घोषित गुण बाद में पता लगाने की तुलना में सही हैं कि सभी उपयोगकर्ता अचानक "इवानोव इवानोव इवानिच" बन जाते हैं, लेकिन कोई भी कमी नहीं है।