POST/api/auth/sso/exchange

একটি SSO লগইনের (SAML/OIDC) শেষ ধাপ: কলব্যাক কর্তৃক প্রদত্ত এককালীন কোডটি একটি নিয়মিত সেশন JWT-এর সাথে বিনিময় করা হয়।

পেজটি „POST /api/auth/sso/exchange — API-Referenz“ URL-এ নির্দেশিত কার্যক্ষেত্র নিয়ে আলোচনা করে। বর্তমান বিষয়বস্তুতে প্রকৃত প্রক্রিয়া, পূর্বশর্ত এবং পরিচিত সীমাবদ্ধতাগুলি যুক্ত করা হয়েছে। Zentor-এর কোনো ডেভেলপার API-কি সিস্টেম নেই। ড্যাশবোর্ডের জন্য সেশন JWT ব্যবহার করা হয় যার মেয়াদ বারো ঘণ্টা এবং রিফ্রেশ টোকেনের মেয়াদ সাত দিন; TOTP এবং SSO ঐচ্ছিক। উইজেট এমবেড টোকেন একবার প্লেইন টেক্সটে দেখানো হয় এবং সেগুলি অনুমোদিত Origins-এর সাথে আবদ্ধ। `POST /api/auth/sso/exchange`-এর ডকুমেন্টেশন অবশ্যই এই নির্দিষ্ট এন্ডপয়েন্টের একটি বাধ্যতামূলক প্রযুক্তিগত বিবরণ হিসেবে পড়া উচিত। মেথড, পাথ, অথেনটিকেশন, বাধ্যতামূলক ফিল্ড, সম্ভাব্য ত্রুটি এবং একটি পুনরাবৃত্ত কল একই প্রভাব সৃষ্টি করে কিনা — এই বিষয়গুলো গুরুত্বপূর্ণ। এই সহায়তা বিভাগটি https://zentor-app.de/hilfe/api-referenz/auth/auth.sso_exchange-এ তাই কোনো সাধারণ প্রচারমূলক বিবৃতি থাকা উচিত নয়, বরং শুধুমাত্র অনুসরণযোগ্য ইন্টিগ্রেশন ধাপ এবং প্রমাণিত রেসপন্স উদাহরণ থাকা উচিত। `/api/auth/sso/exchange` কল করার জন্য, রেজিস্ট্রি অনুযায়ী অনুরোধ তৈরি করা হয়। পাবলিক রুটগুলির জন্য সাধারণ ডেভেলপার API কী-এর প্রয়োজন হয় না, কারণ Zentor এই ধরনের কী সিস্টেম অফার করে না। অন্যদিকে, সুরক্ষিত উইজেট রুটগুলি একবার দেখানো এমবেড টোকেন এবং একটি অরিজিন যাচাই ব্যবহার করে। HTTP স্ট্যাটাস এবং JSON বিষয়বস্তু একসাথে মূল্যায়ন করতে হবে; একটি `ok` ফিল্ড একা ত্রুটি পরিচালনার বিকল্প নয়। `POST /api/auth/sso/exchange` পরীক্ষা করার সময়, বেনামী মান ব্যবহার করতে হবে। প্রকৃত গ্রাহক ডেটা, প্রোডাকশন UUID, সেশন টোকেন এবং নির্দিষ্ট টাইমস্ট্যাম্প পাবলিক উদাহরণে থাকা উচিত নয়। পরিচিত প্ল্যাটফর্ম-ব্যাপী সীমা হল 15 মিনিটের মধ্যে 2,000 অনুরোধ; একটি ভিন্ন পৃথক সীমা প্রমাণিত নয়। নন-আইডেমপোটেন্ট POST কলগুলি একটি অস্পষ্ট নেটওয়ার্ক বিঘ্নের পরে অন্ধভাবে পুনরাবৃত্তি করা উচিত নয়। এই রুটের জন্য সাধারণ ইন্টিগ্রেশন ত্রুটিগুলি তৈরি হয় অনুপস্থিত বাধ্যতামূলক প্যারামিটার, ভুল ডেটা টাইপ, মেয়াদোত্তীর্ণ ওয়ান-টাইম কোড, অননুমোদিত অরিজিন বা একটি অ-বাস্তবায়িত ডেটাসেটের কারণে। অ্যাপ্লিকেশনের উচিত এই ধরনের ক্ষেত্রেগুলি আলাদাভাবে পরিচালনা করা এবং এন্ডপয়েন্ট থেকে ফেরত আসা ত্রুটি বার্তাটি লগ করা, গোপনীয় বিষয়বস্তু লেখা ছাড়াই। একটি সফল রিকোয়েস্ট শুধুমাত্র এই প্রসেসিং ধাপটি নিশ্চিত করে, পরবর্তীতে সংযুক্ত ইমেল, পেমেন্ট বা SSO সাফল্য স্বয়ংক্রিয়ভাবে নিশ্চিত করে না। এটি "POST /api/auth/sso/exchange" এর জন্য সরাসরি প্রাসঙ্গিক। এই পৃষ্ঠার প্রযুক্তিগত পরীক্ষা অবশ্যই `app/frontend/src/content/api-reference/`-এর অধীনে থাকা রেজিস্ট্রি এবং সংশ্লিষ্ট ব্যাকএন্ড রুটগুলির উপর নির্ভর করতে হবে। লাইভ-টেস্ট টীকাগুলি কেবল সেই বিষয়টিই দাবি করতে পারে যা প্রকৃতপক্ষে পরীক্ষা করা হয়েছে। একটি নেগেটিভ টেস্ট বা কোড-অ্যানালজি সম্পূর্ণ সাফল্যের প্রমাণ নয়। POST /api/auth/sso/exchange — API-রেফারেন্সের জন্য, তাই নথিভুক্ত কাঠামো, স্বয়ংক্রিয় পরীক্ষা এবং নিশ্চিতভাবে পর্যবেক্ষণ করা লাইভ আচরণের মধ্যে স্পষ্টভাবে পার্থক্য করা প্রয়োজন।

{"code":"SSO-Callback-Redirect থেকে এককালীন কোড"}

{"ok":true,"token":"<JWT>","refreshToken":"<Refresh-Token>"}