58 lines
4.9 KiB
Markdown
58 lines
4.9 KiB
Markdown
# مسدودی ورود مشتریان و مخاطبان
|
|
|
|
در Django Admin، پروفایل مشتری / مخاطب را با شماره موبایل جست‌وجو کنید.
|
|
گزینهٔ «مسدود کردن ورود مشتری / مخاطب» را فعال کنید، «دلیل مسدودی ورود» را
|
|
بنویسید و ذخیره کنید. ثبت مسدودی بدون دلیل در ادمین پذیرفته نمی‌شود.
|
|
برای رفع مسدودی، همان گزینه را غیرفعال کنید و ذخیره کنید.
|
|
|
|
این تنظیم ورود با موبایل و OTP در `/login/` و ورود با رمز عبور در
|
|
`/login/password/` را کنترل می‌کند. دلیل با متن قرمز، فونت برنامه و کادر
|
|
دارای `role="alert"` نمایش داده می‌شود. متن دلیل HTML اجرا نمی‌کند.
|
|
تنظیمات مسدودی در فرم مشتری و فرم مدیریت مخاطبان کارشناسان قابل تغییر نیست.
|
|
|
|
هر بار مسدود کردن، نسخهٔ دسترسی پروفایل را افزایش می‌دهد. نشست‌های ورود
|
|
قدیمی در نخستین درخواست بعدی خارج می‌شوند و حتی پس از رفع مسدودی قابل
|
|
استفاده نیستند؛ ورود مجدد لازم است. نشست‌های قبل از استقرار این قابلیت
|
|
نسخهٔ صفر دارند و تا زمانی که حساب مسدود نشود معتبر می‌مانند.
|
|
|
|
صفحات مشتری هر ۱۰ ثانیه وضعیت نشست را از `/login/access/` بررسی می‌کنند.
|
|
در مرورگر باز و متصل، مسدودی بدون کلیک کاربر نیز باعث انتقال به صفحهٔ
|
|
ورود و نمایش دلیل می‌شود. هنگام بازگشت به تب، باز شدن مجدد صفحه یا اتصال
|
|
دوبارهٔ شبکه هم بررسی انجام می‌شود. کنترل سمت سرور به جاوااسکریپت وابسته نیست.
|
|
|
|
حساب‌های `STAFF`، کاربران دارای `is_staff` و ابرکاربران از این محدودیت
|
|
مستثنا هستند. لینک‌های امن با دسترسی محدود به تیکت یا پرداخت، نشست ورود
|
|
کامل مشتری ایجاد نمی‌کنند و قواعد مستقل قبلی خود را حفظ می‌کنند.
|
|
این قابلیت مقدار `is_active` حساب را تغییر نمی‌دهد.
|
|
|
|
Migration مورد نیاز: `customers.0007_customerprofile_login_access_version_and_more`.
|
|
برای استقرار با پایتون محیط پروژه، `manage.py migrate` را اجرا کنید و سرویس
|
|
Django را دوباره راه‌اندازی کنید.
|
|
|
|
تست‌ها در `tests/test_customer_login_access.py` و
|
|
`tests/e2e/test_customer_login_access_e2e.py` قرار دارند. تست مرورگر از
|
|
`live_server` و Chromium مدیریت‌شدهٔ پروژه استفاده می‌کند.
|
|
|
|
## نتیجهٔ بررسی
|
|
|
|
- مجموعهٔ گستردهٔ ورود، نقش‌ها، مخاطبان، پرداخت‌ها، لینک‌های امن و انتقال
|
|
داده: ۲۶۰ تست موفق.
|
|
- آخرین اجرای پس از اصلاح ترتیب middlewareها: ۸۵ تست موفق، شامل
|
|
`test_customer_login_access.py`، `test_views.py`، `test_role_workflow_regression.py`،
|
|
تست‌های مرورگر مسدودی و `test_pwa_versioning.py`.
|
|
- کنترل‌های Django، نبود migration جاافتاده، بررسی نحو Python و JavaScript
|
|
و `git diff --check` برای فایل‌های این قابلیت موفق بودند.
|
|
- صفحهٔ ورود، CSS قرمز نسخه‌دار و endpoint بدون کش نشست از سرور توسعه
|
|
روی `0.0.0.0:8000` با پاسخ HTTP 200 بررسی شدند.
|
|
|
|
Graphify برای ارتباط مفهومی پروفایل و دسترسی‌ها و Ripwire برای بررسی
|
|
نمادها، اثر تغییر، محل استفاده و گیت‌های پس از تغییر اجرا شدند.
|
|
`test-gate` فهرست تست‌های لازم را ارائه می‌کند و خود تست‌ها را اجرا نمی‌کند؛
|
|
تست‌های معرفی‌شده جداگانه اجرا و موفق شدند. `quality-delta` سبز نشد:
|
|
هشدارهایی دربارهٔ callbackهای Django، تست‌های کشف‌شده توسط pytest و شباهت
|
|
ساختاری توابع بازیابی رکورد باقی مانده است. برای نمونه، بازیابی
|
|
`CustomerProfile` با بازیابی `DispatchResponseControl` شبیه تشخیص داده شد؛
|
|
این دو به مدل‌ها و قواعد مستقل مربوط‌اند و ادغام آن‌ها مناسب نیست.
|
|
این هشدارهای تحلیل ایستا به معنی شکست تست‌های اجرایی نیستند و به‌عنوان
|
|
نتیجهٔ سبز گیت کیفیت گزارش نشده‌اند.
|