3 changed files with 474 additions and 184 deletions
-
100apps/course/tests/test_live_session_api.py
-
292apps/course/views/course.py
-
266docs/online_class_entry_endpoints_guide.md
@ -1,237 +1,149 @@ |
|||
# راهنمای استفاده از endpoint های ورود به کلاس آنلاین |
|||
# راهنمای جدید ورود به کلاس آنلاین |
|||
|
|||
این فایل برای تیمهای `frontend` و `flutter` نوشته شده و فقط توضیح میدهد: |
|||
این فایل برای تیمهای `frontend` و `flutter` نوشته شده و توضیح میدهد که از این به بعد |
|||
برای ورود کاربر به کلاس آنلاین، endpoint اصلی فقط `validate` است. |
|||
|
|||
- هر endpoint چه کاری انجام میدهد |
|||
- در چه شرایطی باید از آن استفاده شود |
|||
- ترتیب درست استفاده از endpoint ها چیست |
|||
## هدف تغییر |
|||
|
|||
این راهنما وارد کدنویسی React یا Flutter نمیشود و فقط منطق استفاده را توضیح میدهد. |
|||
قبلاً کلاینت برای ورود به کلاس باید بین چند endpoint تصمیم میگرفت: |
|||
|
|||
## هدف کلی |
|||
- `online/validate` |
|||
- `online/token` |
|||
- `online/room/token` |
|||
|
|||
کاربر برای ورود به کلاس آنلاین دو حالت دارد: |
|||
این کار باعث میشد منطق تصمیمگیری، ساخت token و تشخیص مسیر redirect در کلاینت پخش شود. |
|||
|
|||
1. کلاس هنوز توسط استاد شروع نشده است |
|||
2. کلاس از قبل شروع شده و room فعال است |
|||
الان این تصمیمگیری به بکند منتقل شده است. |
|||
|
|||
رفتار درست فرانت باید بر اساس همین دو حالت تعیین شود. |
|||
## endpoint اصلی |
|||
|
|||
## اصل مهم |
|||
|
|||
فرانت نباید با درخواست اشتباه باعث ساختن کلاس توسط دانشجو شود. |
|||
|
|||
بنابراین: |
|||
|
|||
- اگر کلاس شروع نشده باشد، کاربر باید وارد `waiting page` شود |
|||
- اگر کلاس شروع شده باشد، کاربر باید مستقیم `join token` واقعی بگیرد و وارد کلاس شود |
|||
|
|||
## endpoint ها |
|||
|
|||
### 1. بررسی وضعیت کلاس |
|||
|
|||
#### Endpoint |
|||
### بررسی وضعیت کلاس و گرفتن مسیر نهایی ورود |
|||
|
|||
`GET /api/courses/<course-slug>/online/validate/` |
|||
|
|||
#### کاربرد |
|||
|
|||
این endpoint برای تصمیمگیری اولیه فرانت است. |
|||
|
|||
با این endpoint میتوان فهمید: |
|||
|
|||
- آیا کلاس الان آنلاین است یا نه |
|||
- آیا کاربر اجازه ورود به کلاس را دارد یا نه |
|||
- آیا کاربر استاد است و میتواند کلاس را شروع کند یا نه |
|||
|
|||
#### خروجی مهم |
|||
|
|||
فیلدهای مهم در `metadata`: |
|||
|
|||
- `is_online` |
|||
- `can_join_live_session` |
|||
- `can_create_live_session` |
|||
- `has_finished` |
|||
|
|||
#### زمان استفاده |
|||
|
|||
این endpoint باید قبل از تصمیم نهایی برای ورود به کلاس صدا زده شود. |
|||
|
|||
#### تصمیمگیری بر اساس پاسخ |
|||
|
|||
- اگر `is_online = true` و `can_join_live_session = true` |
|||
فرانت باید مستقیم به سراغ گرفتن `join token` واقعی برود |
|||
|
|||
- اگر `is_online = false` |
|||
فرانت نباید مستقیم سراغ `room/token` برود و باید از flow صفحه انتظار استفاده کند |
|||
|
|||
- اگر `can_create_live_session = true` |
|||
کاربر استاد است و فرانت باید مستقیم به سراغ گرفتن `join token` واقعی برود |
|||
|
|||
--- |
|||
|
|||
### 2. ساخت لینک ورود موقت برای waiting page |
|||
|
|||
#### Endpoint |
|||
|
|||
`POST /api/courses/<course_id>/online/token/` |
|||
## کاری که این endpoint انجام میدهد |
|||
|
|||
#### کاربرد |
|||
این endpoint حالا همه این کارها را یکجا انجام میدهد: |
|||
|
|||
این endpoint برای ورود به waiting flow استفاده میشود. |
|||
- وضعیت کلاس را بررسی میکند |
|||
- مشخص میکند کاربر اجازه ورود دارد یا نه |
|||
- اگر کلاس شروع شده باشد، `access_token` مستقیم کلاس را میسازد |
|||
- اگر کلاس شروع نشده باشد، `temporary token` صفحه انتظار را میسازد |
|||
- مسیر نهایی redirect را در `redirect_path` برمیگرداند |
|||
|
|||
این endpoint: |
|||
## منطق پاسخ |
|||
|
|||
- یک `temporary token` میسازد |
|||
- یک URL ورود به `conference_client` برمیگرداند |
|||
### اگر کلاس آنلاین باشد |
|||
|
|||
#### چه زمانی باید استفاده شود |
|||
بکند: |
|||
|
|||
فقط وقتی که کلاس هنوز شروع نشده است. |
|||
- `join token` واقعی PlugNMeet را میسازد |
|||
- کاربر را باید به مسیر مستقیم کلاس هدایت کرد |
|||
|
|||
#### چه زمانی نباید استفاده شود |
|||
نمونه: |
|||
|
|||
اگر کلاس از قبل شروع شده و room فعال است، نباید این endpoint مسیر اصلی ورود باشد. |
|||
`https://meet.example.com/?access_token=<access_token>` |
|||
|
|||
در آن حالت باید مستقیم `join token` واقعی گرفته شود. |
|||
### اگر کلاس هنوز آنلاین نشده باشد |
|||
|
|||
#### ورودی |
|||
بکند: |
|||
|
|||
- `course_id` در URL |
|||
- هدر احراز هویت کاربر |
|||
- `temporary token` صفحه انتظار را میسازد |
|||
- کاربر را باید به flow انتظار/پریجوین هدایت کرد |
|||
|
|||
بدنه عملا میتواند خالی باشد. |
|||
نمونه: |
|||
|
|||
#### خروجی |
|||
`https://meet.example.com/?token=<temporary_token>&slug=<course_slug>` |
|||
|
|||
پاسخ شامل این فیلدهاست: |
|||
### اگر کلاس هنوز آنلاین نشده باشد و کاربر استاد باشد |
|||
|
|||
- `token` |
|||
- `url` |
|||
- `expires_in` |
|||
بکند: |
|||
|
|||
- room را همان لحظه میسازد |
|||
- `access_token` مستقیم ورود به کلاس را برمیگرداند |
|||
- استاد مستقیم وارد خود کلاس میشود |
|||
|
|||
### 3. گرفتن join token واقعی برای ورود مستقیم به کلاس |
|||
نمونه: |
|||
|
|||
#### Endpoint |
|||
`https://meet.example.com/?access_token=<access_token>` |
|||
|
|||
`POST /api/courses/online/room/token/` |
|||
## فیلد مهم جدید |
|||
|
|||
#### کاربرد |
|||
در پاسخ این endpoint، فیلد `redirect_path` برگردانده میشود. |
|||
|
|||
این endpoint `access_token` واقعی PlugNMeet را میسازد. |
|||
کلاینت باید فقط از همین فیلد برای navigation استفاده کند. |
|||
|
|||
با این token کاربر مستقیم وارد کلاس میشود. |
|||
## ساختار پاسخ |
|||
|
|||
#### چه زمانی باید استفاده شود |
|||
پاسخ همچنان شامل این بخشهاست: |
|||
|
|||
وقتی که کلاس از قبل شروع شده و room فعال است. |
|||
- `course` |
|||
- `user` |
|||
- `metadata` |
|||
- `redirect_path` |
|||
|
|||
#### چه زمانی نباید استفاده شود |
|||
فیلد `metadata.redirect_path` هم با همین مقدار نهایی پر میشود تا سازگاری قبلی حفظ شود. |
|||
|
|||
وقتی هنوز کلاس شروع نشده است. |
|||
## رفتار پیشنهادی کلاینت |
|||
|
|||
در آن حالت این endpoint مسیر مناسب ورود نیست و باید از waiting flow استفاده شود. |
|||
### سناریوی استاندارد |
|||
|
|||
#### ورودی |
|||
1. کاربر روی دکمه ورود به کلاس میزند |
|||
2. کلاینت فقط `online/validate` را صدا میزند |
|||
3. اگر `redirect_path` مقدار داشت: |
|||
- کاربر به همان مسیر هدایت میشود |
|||
4. اگر `redirect_path` مقدار نداشت: |
|||
- یعنی کاربر اجازه ورود ندارد یا هنوز شرایط ورود برای او مهیا نیست |
|||
|
|||
بدنه: |
|||
## معنی فیلدهای مهم metadata |
|||
|
|||
`course_slug` |
|||
|
|||
به همراه هدر احراز هویت کاربر |
|||
|
|||
#### خروجی |
|||
|
|||
پاسخ شامل: |
|||
|
|||
- `room_id` |
|||
- `token` |
|||
|
|||
#### رفتار درست بعد از دریافت پاسخ |
|||
|
|||
کاربر باید مستقیم به `conference_client` با `access_token` هدایت شود. |
|||
|
|||
مثال: |
|||
|
|||
`https://meet.imamjavad.online/?access_token=<access_token>` |
|||
|
|||
|
|||
## ترتیب درست استفاده در فرانت |
|||
|
|||
### سناریو 1: کاربر روی دکمه ورود به کلاس میزند |
|||
|
|||
ترتیب درست: |
|||
|
|||
1. فرانت وضعیت کلاس را با `online/validate` بررسی کند |
|||
2. اگر کلاس فعال بود: |
|||
- `online/room/token/` |
|||
- هدایت مستقیم با `access_token` |
|||
3. اگر کلاس فعال نبود: |
|||
- `online/token/` |
|||
- هدایت کاربر به waiting page |
|||
|
|||
## منطق تصمیمگیری پیشنهادی |
|||
|
|||
- `is_online = true` |
|||
مسیر درست: ورود مستقیم به کلاس |
|||
|
|||
- `is_online = false` |
|||
مسیر درست: waiting page |
|||
|
|||
## رفتار داخل conference_client |
|||
|
|||
`conference_client` الان دو ورودی را میفهمد: |
|||
|
|||
### حالت اول: ورود مستقیم |
|||
|
|||
اگر URL شامل این باشد: |
|||
- `is_online` |
|||
- `can_join_live_session` |
|||
- `can_create_live_session` |
|||
- `has_finished` |
|||
- `redirect_path` |
|||
|
|||
- `access_token` |
|||
## نکته مهم برای صفحه انتظار |
|||
|
|||
کاربر مستقیم وارد flow اصلی کلاس میشود. |
|||
اگر `redirect_path` از نوع `?token=...&slug=...` باشد: |
|||
|
|||
### حالت دوم: waiting flow |
|||
- کاربر وارد `conference_client` میشود |
|||
- صفحه انتظار یا pre-join نمایش داده میشود |
|||
- اگر استاد باشد، میتواند از همان flow کلاس را شروع کند |
|||
- اگر دانشجو باشد، منتظر شروع کلاس میماند |
|||
|
|||
اگر URL شامل این باشد: |
|||
اگر کاربر استاد باشد و کلاس هنوز شروع نشده باشد: |
|||
|
|||
- `token` |
|||
- `slug` |
|||
- `redirect_path` باید مستقیم از نوع `?access_token=...` باشد |
|||
- کلاینت نباید استاد را به waiting page بفرستد |
|||
|
|||
کاربر وارد waiting/pre-join flow میشود. |
|||
## نکته مهم برای ورود مستقیم |
|||
|
|||
در این حالت: |
|||
اگر `redirect_path` از نوع `?access_token=...` باشد: |
|||
|
|||
1. temporary token به auth token واقعی تبدیل میشود |
|||
2. وضعیت کلاس از Django خوانده میشود |
|||
3. اگر کلاس هنوز شروع نشده باشد، waiting page نمایش داده میشود |
|||
4. اگر کلاس شروع شده باشد، دکمه ورود به کلاس نمایش داده میشود |
|||
5. اگر کاربر استاد باشد و کلاس شروع نشده باشد، دکمه شروع کلاس نمایش داده میشود |
|||
- کاربر مستقیم وارد کلاس میشود |
|||
- دیگر نیازی نیست کلاینت جداگانه `room/token` را صدا بزند |
|||
|
|||
## آپدیت خودکار وضعیت |
|||
## وضعیت endpoint های قبلی |
|||
|
|||
در waiting flow، وضعیت کلاس به صورت polling دورهای از Django بررسی میشود. |
|||
endpoint های زیر هنوز ممکن است برای سازگاری یا استفاده داخلی موجود باشند: |
|||
|
|||
بنابراین: |
|||
- `POST /api/courses/<course_id>/online/token/` |
|||
- `POST /api/courses/online/room/token/` |
|||
|
|||
- اگر استاد کلاس را شروع کند، صفحه انتظار بهروزرسانی میشود |
|||
- اگر استاد کلاس را ببندد، وضعیت صفحه دوباره به حالت انتظار/پایان بازمیگردد |
|||
اما برای flow اصلی ورود کاربر، کلاینت جدید نباید روی آنها تصمیمگیری انجام دهد. |
|||
|
|||
## جمعبندی نهایی |
|||
|
|||
### برای فرانت اصلی سایت یا اپ |
|||
|
|||
- ابتدا همیشه `online/validate` |
|||
- اگر کلاس فعال بود: `online/room/token/` |
|||
- اگر کلاس فعال نبود: `online/token/` |
|||
|
|||
### برای conference_client |
|||
برای ورود کاربر به کلاس: |
|||
|
|||
- اگر `access_token` داشت: ورود مستقیم |
|||
- اگر `token + slug` داشت: waiting flow |
|||
- فقط `online/validate` را صدا بزنید |
|||
- فقط `redirect_path` را بخوانید |
|||
- بر اساس آن redirect کنید |
|||
|
|||
### قاعده مهم |
|||
یعنی منطق انتخاب بین: |
|||
|
|||
`online/token/` برای قبل از شروع کلاس است |
|||
- صفحه انتظار |
|||
- ورود مستقیم به کلاس |
|||
|
|||
`online/room/token/` برای وقتی است که کلاس واقعا شروع شده است |
|||
دیگر مسئولیت کلاینت نیست و در بکند انجام میشود. |
|||
Write
Preview
Loading…
Cancel
Save
Reference in new issue