- शिप
- 23 सितंबर 2026 को 3:08 am बजे UTC
- लेखक
- Kamo
- Commit
- 6f10239
रिंगसेंट्रल के इनबाउंड कॉल / एसएमएस वेबहुक को शून्य सत्यापन के साथ संसाधित किया गया था: वेबहुककंट्रोलर ने सीधे टेलीफ़ोनी / संदेश-स्टोर की घटनाओं को रूट किया ************* ************* `return true; // TODO`, और सदस्यता को सत्यापन के बिना बनाया गया था बिल्कुल. समापन बिंदु सार्वजनिक है। जो कोई भी एक शिल्प पेलोड पोस्ट करता है उसे एक इंजेक्शन दे सकता है किसी भी ओरग में टेक्स्ट, फोर्ज STOP/START अनुपालन की घटनाओं, एक इनबाउंड-कॉल पॉपअप ट्रिगर एक मनमाने ढंग से संख्या (टोल-फ्रॉड आसन्न), या "से" सामग्री के लिए दिखाया गया एक सदस्य - और to-number संकल्प (`findByFromPhoneNumber`) कभी भी गुंजाइश नहीं किया गया था इसलिए एक वास्तविक ग्राहक की संख्या मिलान की जा सकती है और गलत किरायेदार को दिखाया जा सकता है यहां तक कि एक वास्तविक दिखने पेलोड द्वारा भी। ठीक करें: - रिंगसेंट्रलवेबहुकप्रोविज़नर अब एक यादृच्छिक प्रति इंस्टेंस सत्यापन टोकन उत्पन्न करता है (config json में खड़े होकर, सेटिंग्स एपीआई से मुक्त), सदस्यता पंजीकृत करता है Per-instance URL (`?instanceId=`, मैचिंग टीम/JustCall) पर, और टोकन भेजता है के रूप में ************* तो रिंगसेंट्रल इसे वापस के रूप में echoes हर अधिसूचना पर `Verification-Token` header। रिंगसेंट्रल की अपनी सदस्यता URL-ownership handhake ( `Validation-Token` header WebhookController पहले से ही वापस गूंजें) untouched है - यह एक अलग हेडर है जो एक अलग चीज़ साबित करता है। - ************* अब जांचें कि हेडर स्थिर में समय और विफल रहता है (अब तक कोई टोकन नहीं, कोई हैडर नहीं, या सभी मना कर दिया है)। - वेबहुककंट्रोलर इस उदाहरण को `इंस्टेंस' से हल करता है Id=`, की आवश्यकता है सत्यापन-टोकन जांच पास करने के लिए, और उसके बाद ही इस घटना को संसाधित करता है - वह उदाहरण है। ************* ************* दोनों ने एक सत्यापितऑर्गिड पैरामीटर प्राप्त किया: एक to-number वेब सत्यापितहुक की तुलना में एक डिफरेंट ऑर्ग में मैच का अनावरण माना जाता है, वास्तव में, वास्तव में कोई भी व्यक्ति के पास नहीं है, कभी भरोसा नहीं है। - सुरक्षा की तैनाती (3 लाइव रिंगसेंट्रल उदाहरणों को भीतर की यातायात नहीं खोना चाहिए): रिंगसेंट्रलवेबहुकप्रोविज़नर के हर पास अब खाते के वास्तविक होने के बावजूद है सदस्यता सूची - एक पूर्व-फिक्स सदस्यता (कोई उदाहरण नहींआईडी / टोकन) को डील किया जाता है और एक सत्यापित के साथ प्रतिस्थापित, इसलिए नए के ~ 30s के भीतर स्व-चिकित्सा उदाहरण फली बनने का नेता (यह पहले से ही स्टार्टअप + हर 12h पर चलता है)। पहले अंतराल के लिए यह पूरी तरह से ठीक हो जाता है, वेबहुककंट्रोलर अभी भी एक घटना को स्वीकार नहीं करता है सभी के तहत पूर्व निर्धारित, unscoped नियमों - लेकिन केवल 2026-10-13 तक, और हर लॉग इन करें लाइन इसलिए गिरावट दिखाई दे रही है और स्थायी नहीं। उस तारीख के बाद यह सब कुछ और की तरह बंद हो जाता है। समन्वयक के लिए रिपोर्ट: 3 लाइव रिंगसेंट्रल उदाहरणों के लिए कोई कार्रवाई की आवश्यकता नहीं है - वे अगली तैनाती पर स्वचालित रूप से ठीक हो जाते हैं। क्रमिक रूप से, देखने के लिए ************* इस तैनाती के बाद वीओआईपीसर्व लॉग में; यह होना चाहिए मिनट के भीतर दिखाई देना बंद करो। अगर यह अभी भी 2026-10-13 के करीब दिखाई दे रहा है, तो पता करें क्यों उस उदाहरण की सदस्यता को ठीक नहीं किया गया था (RingCentralJwtTokenService विफलताओं) अलग से लॉग इन कर रहे हैं) कटओवर से पहले, या विस्तार ************* टेस्ट: ************* (fails no token/header के साथ बंद) गलत टोकन, मिलान टोकन स्वीकार करता है, केस असंवेदनशील हेडर), ************* (generates + perist + token को पुन: उपयोग करता है; एक को हटा देता है पूर्व निर्धारित सदस्यता और एक सत्यापित प्रतिस्थापन रजिस्टर; एक स्वस्थ वर्तमान छोड़ देता है अकेले सदस्यता), साथ ही ऑर्ग-स्कपिंग के मामलों को VoipCallEventService में जोड़ा गया टेस्ट और टेस्ट VoipMessageServiceKeywordTest. सभी चार उत्परिवर्तन-चेक: प्रासंगिक को उलट देना गार्ड इसी परीक्षण लाल हो जाता है, इसे बहाल करने से यह हरा हो जाता है।.