dovodi
/
Dovodi_Backend
3
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
704 Commits
1 Branch
0 Tags
149 MiB
 
 
 
 
Tree: 0066c07de4
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '0066c07de4'
${ noResults }
Dovodi_Backend/docs/online_class_entry_endpoint...

5.2 KiB
Raw Blame History

راهنمای جدید ورود به کلاس آنلاین

این فایل برای تیم‌های frontend و flutter نوشته شده و توضیح می‌دهد که از این به بعد برای ورود کاربر به کلاس آنلاین، endpoint اصلی فقط validate است.

هدف تغییر

قبلاً کلاینت برای ورود به کلاس باید بین چند endpoint تصمیم می‌گرفت:

  • online/validate
  • online/token
  • online/room/token

این کار باعث می‌شد منطق تصمیم‌گیری، ساخت token و تشخیص مسیر redirect در کلاینت پخش شود.

الان این تصمیم‌گیری به بکند منتقل شده است.

endpoint اصلی

بررسی وضعیت کلاس و گرفتن مسیر نهایی ورود

GET /api/courses/<course-slug>/online/validate/

کاری که این endpoint انجام می‌دهد

این endpoint حالا همه این کارها را یکجا انجام می‌دهد:

  • وضعیت کلاس را بررسی می‌کند
  • مشخص می‌کند کاربر اجازه ورود دارد یا نه
  • اگر کلاس شروع شده باشد، access_token مستقیم کلاس را می‌سازد
  • اگر کلاس شروع نشده باشد، temporary token صفحه انتظار را می‌سازد
  • مسیر نهایی redirect را در redirect_path برمی‌گرداند

منطق پاسخ

اگر کلاس آنلاین باشد

بکند:

  • join token واقعی PlugNMeet را می‌سازد
  • کاربر را باید به مسیر مستقیم کلاس هدایت کرد

نمونه:

https://meet.example.com/?access_token=<access_token>

اگر کلاس هنوز آنلاین نشده باشد

بکند:

  • temporary token صفحه انتظار را می‌سازد
  • کاربر را باید به flow انتظار/پری‌جوین هدایت کرد

نمونه:

https://meet.example.com/?token=<temporary_token>&slug=<course_slug>

اگر کلاس هنوز آنلاین نشده باشد و کاربر استاد باشد

بکند:

  • room را همان لحظه می‌سازد
  • access_token مستقیم ورود به کلاس را برمی‌گرداند
  • استاد مستقیم وارد خود کلاس می‌شود

نمونه:

https://meet.example.com/?access_token=<access_token>

فیلد مهم جدید

در پاسخ این endpoint، فیلد redirect_path برگردانده می‌شود.

کلاینت باید فقط از همین فیلد برای navigation استفاده کند.

ساختار پاسخ

پاسخ همچنان شامل این بخش‌هاست:

  • course
  • user
  • metadata
  • redirect_path

فیلد metadata.redirect_path هم با همین مقدار نهایی پر می‌شود تا سازگاری قبلی حفظ شود.

رفتار پیشنهادی کلاینت

سناریوی استاندارد

  1. کاربر روی دکمه ورود به کلاس می‌زند
  2. کلاینت فقط online/validate را صدا می‌زند
  3. اگر redirect_path مقدار داشت:
    • کاربر به همان مسیر هدایت می‌شود
  4. اگر redirect_path مقدار نداشت:
    • یعنی کاربر اجازه ورود ندارد یا هنوز شرایط ورود برای او مهیا نیست

معنی فیلدهای مهم metadata

  • is_online
  • can_join_live_session
  • can_create_live_session
  • has_finished
  • redirect_path

نکته مهم برای صفحه انتظار

اگر redirect_path از نوع ?token=...&slug=... باشد:

  • کاربر وارد conference_client می‌شود
  • صفحه انتظار یا pre-join نمایش داده می‌شود
  • اگر استاد باشد، می‌تواند از همان flow کلاس را شروع کند
  • اگر دانشجو باشد، منتظر شروع کلاس می‌ماند

اگر کاربر استاد باشد و کلاس هنوز شروع نشده باشد:

  • redirect_path باید مستقیم از نوع ?access_token=... باشد
  • کلاینت نباید استاد را به waiting page بفرستد

نکته مهم برای ورود مستقیم

اگر redirect_path از نوع ?access_token=... باشد:

  • کاربر مستقیم وارد کلاس می‌شود
  • دیگر نیازی نیست کلاینت جداگانه room/token را صدا بزند

وضعیت endpoint های قبلی

endpoint های زیر هنوز ممکن است برای سازگاری یا استفاده داخلی موجود باشند:

  • POST /api/courses/<course_id>/online/token/
  • POST /api/courses/online/room/token/

اما برای flow اصلی ورود کاربر، کلاینت جدید نباید روی آن‌ها تصمیم‌گیری انجام دهد.

جمع‌بندی نهایی

برای ورود کاربر به کلاس:

  • فقط online/validate را صدا بزنید
  • فقط redirect_path را بخوانید
  • بر اساس آن redirect کنید

یعنی منطق انتخاب بین:

  • صفحه انتظار
  • ورود مستقیم به کلاس

دیگر مسئولیت کلاینت نیست و در بکند انجام می‌شود.