POST/api/auth/sso/exchange
SSO लगइनको अन्तिम चरण (SAML/OIDC): कलब्याकबाट जारी गरिएको एक पटकको कोडलाई नियमित सत्र JWT को लागि बदल्दछ।
यो „POST /api/auth/sso/exchange — API-Referenz" पृष्ठले URL मा उल्लेख गरिएको कार्यक्षेत्रलाई सम्बोधन गर्दछ। विद्यमान सामग्रीमा वास्तविक प्रक्रिया, आवश्यक सर्तहरू र ज्ञात सीमाहरू थपिएका छन्। Zentor सँग डेभलपर API-कुञ्जी प्रणाली छैन। ड्यासबोर्डका लागि बाह्र घण्टा वैधता अवधि भएको Session-JWT र सात दिन वैधता अवधि भएको Refresh-Token प्रयोग गरिन्छ; TOTP र SSO वैकल्पिक छन्। Widget-Embed-Token एक पटक मात्र स्पष्ट पाठमा देखाइन्छ र स्वीकृत Origin सँग बाँधिएको हुन्छ। `POST /api/auth/sso/exchange` को दस्ताबेजलाई यस ठोस एन्डपोइन्टको बाध्यकारी प्राविधिक विवरणका रूपमा पढ्नुपर्छ। निर्णायक कुराहरू हुन्: विधि, पथ, प्रमाणीकरण, अनिवार्य फिल्डहरू, सम्भावित त्रुटिहरू, र फेरि कल गर्दा उस्तै प्रभाव पर्छ कि पर्दैन भन्ने प्रश्न। यसैले सहायता खण्ड https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange मा कुनै सामान्य विज्ञापनात्मक भनाइ हुनु हुँदैन, बरु केवल पछ्याउन सकिने एकीकरण चरणहरू र प्रमाणित प्रतिक्रिया उदाहरणहरू मात्र हुनुपर्छ। `/api/auth/sso/exchange` लाई कल गर्न रजिस्ट्री अनुसार अनुरोध बनाइन्छ। सार्वजनिक रूटहरूलाई सामान्य डेभलपर API-कुञ्जी आवश्यक पर्दैन, किनभने Zentor ले त्यस्तो कुञ्जी प्रणाली प्रदान गर्दैन। यसको विपरीत, सुरक्षित Widget रूटहरूले एक पटक मात्र देखाइने Embed-Token र Origin जाँच प्रयोग गर्छन्। HTTP स्टेटस र JSON सामग्री सँगै मूल्यांकन गर्नुपर्छ; एक्लै `ok` फिल्डले त्रुटि व्यवस्थापनको विकल्प दिँदैन। `POST /api/auth/sso/exchange` परीक्षण गर्दा अज्ञातनामीकृत मानहरू प्रयोग गर्नुपर्छ। वास्तविक ग्राहक डेटा, उत्पादनका UUID, सेसन टोकन र ठोस समय-मुद्रा सार्वजनिक उदाहरणहरूमा समावेश गर्नु हुँदैन। ज्ञात प्लेटफर्म-व्यापी सीमा 15 मिनेटभित्र 2,000 अनुरोध हो; यसभन्दा फरक कुनै एकल सीमा प्रमाणित गरिएको छैन। गैर-आइडेम्पोटेन्ट POST कलहरूलाई अस्पष्ट नेटवर्क अवरोधपछि आँखा चिम्लेर दोहोर्याउनु हुँदैन। यस रूटका लागि सामान्य एकीकरण त्रुटिहरू अनिवार्य प्यारामिटर छुटेको, गलत डेटा प्रकार, म्याद सकिएको एकपटके कोड, अस्वीकृत Origin वा कार्यान्वयन नगरिएको डेटासेटका कारण उत्पन्न हुन्छन्। एप्लिकेसनले यस्ता अवस्थाहरूलाई छुट्टाछुट्टै व्यवस्थापन गर्नुपर्छ र एन्डपोइन्टबाट फर्किएको त्रुटि सन्देश गोप्य सामग्री नराखी लग गर्नुपर्छ। सफल Request ले केवल यही प्रशोधन चरण मात्र पुष्टि गर्छ, त्यसपछि जोडिएको इमेल, भुक्तानी वा SSO सफलता स्वतः पुष्टि गर्दैन। यो कुरा „POST /api/auth/sso/exchange" का लागि प्रत्यक्ष रूपमा सान्दर्भिक छ। यस पृष्ठको प्राविधिक जाँच `app/frontend/src/content/api-reference/` अन्तर्गतको रजिस्ट्री र सम्बन्धित ब्याकइन्ड रूटहरूमा अनिवार्य रूपमा आधारित हुनुपर्छ। Live-परीक्षण टिप्पणीहरूले केवल वास्तवमा जाँचिएको कुरा मात्र दाबी गर्न सक्छन्। नकारात्मक परीक्षण वा कोड-समानता पूर्ण सफलताको प्रमाण होइन। POST /api/auth/sso/exchange — API-Referenz का लागि त्यसैले दस्ताबेजीकृत संरचना, स्वचालित परीक्षण, र सुरक्षित रूपमा अवलोकन गरिएको Live व्यवहार बीच स्पष्ट भिन्नता कायम राख्नुपर्छ।
Auth & Absicherung
Keine Authentifizierung erforderlich
Idempotent: Nein
Parameter
code(body, string, erforderlich)— SSO रिडायरेक्टबाट एक पटकको प्रतिस्थापन कोडBeispiel-Request
{"code":"<SSO-Callback-Redirect बाट एक पटकको कोड>"}Beispiel-Response
{"ok":true,"token":"<JWT>","refreshToken":"<Refresh-Token>"}Fehlercodes
400 SSO_EXCHANGE_INVALID — प्रतिस्थापन कोड अमान्य, प्रयोग गरिएको वा समाप्त भएको छ।Live-Test-Nachweis
नकारात्मक मामला (400) काल्पनिक कोडको साथ प्रत्यक्ष प्रमाणित; सफल मामलाले पूर्ण SAML/OIDC रिडायरेक्ट पूर्ण-प्रवाहको आवश्यकता पर्दछ वास्तविक पहिचान प्रदायकको साथ, यो परीक्षण वातावरणमा पुनः निर्माण गरिएको छैन।