محتوای آموزشی وبلاگ نت‌آرام
کاربر نام کاربری و رمز را درست وارد می‌کند و ظاهراً وارد سایت Flask می‌شود، اما با تازه‌کردن صفحه یا رفتن به بخش دیگر دوباره صفحه ورود را می‌بیند. این حالت لزوماً به معنی اشتباه بودن رمز نیست. ممکن است مرورگر کوکی نشست را نگرفته باشد، آن را به دامنه دیگری نفرستد یا برنامه نتواند نشست ذخیره‌شده را با کلید فعلی اعتبارسنجی کند.
در این راهنما مسیر ورود را با یک حساب آزمایشی بررسی می‌کنیم، سپس دلیل‌های رایج را یکی‌یکی رفع می‌کنیم. مثال‌ها برای Flask روی هاست پایتون و یک برنامه وب معمولی هستند. اگر پروژه از افزونه یا ذخیره‌ساز نشست دیگری استفاده می‌کند، علاوه بر این موارد باید تنظیمات همان افزونه و محل ذخیره‌سازی آن را هم بررسی کنید.
پیش از شروع: نشست را با رمز اشتباه نگیرید
با یک حساب آزمایشی وارد شوید و دقیقاً بنویسید چه زمانی از حساب خارج می‌شوید: بلافاصله پس از ورود، فقط پس از رفتن از
example.com به www.example.com، پس از بستن مرورگر یا فقط بعد از راه‌اندازی دوباره برنامه؟ هر الگو سرنخ متفاوتی دارد. اگر رمز پذیرفته نمی‌شود و اصلاً پیام ورود موفق نمی‌بینید، ابتدا منطق احراز هویت را بررسی کنید.یک پنجره خصوصی مرورگر باز کنید و همان مسیر را با دامنه واقعی تکرار کنید. اگر فقط یک مرورگر مشکل دارد، کوکی‌های قدیمی آن سایت یا افزونه‌ها را هم در نظر بگیرید. از کپی‌کردن مقدار کوکی، کلید برنامه یا رمز کاربر در تصویر و پیام پشتیبانی خودداری کنید.
در حالت پیش‌فرض Flask، داده نشست در کوکی امضاشده نگهداری می‌شود. امضا جلوی تغییر بی‌اجازه محتوا را می‌گیرد، اما محتوا را به‌خودی‌خود محرمانه یا رمزگذاری‌شده نمی‌کند. بنابراین رمز کاربر یا کلید API را داخل session قرار ندهید.
۱. دریافت و ارسال کوکی را در مرورگر ببینید
کلید
F12 را بزنید و زبانه Network را باز کنید. ورود آزمایشی را انجام دهید و روی درخواست پاسخ ورود کلیک کنید. در پاسخ دنبال تنظیم کوکی نشست و در تب مربوط به Cookies یا Storage دنبال نام آن بگردید؛ نام پیش‌فرض معمولاً session است، اما برنامه می‌تواند آن را تغییر داده باشد. مرورگر ممکن است دلیل رد کوکی را کنار همان پاسخ نشان دهد.سپس صفحه‌ای را که کاربر را خارج‌شده نشان می‌دهد باز کنید و ببینید آیا مرورگر کوکی مناسب را در درخواست بعدی ارسال کرده است. مقدار کوکی را لازم نیست بخوانید یا جایی کپی کنید؛ وجود، دامنه، مسیر، وضعیت Secure و پیام رد کافی‌اند.
اگر پاسخ ورود اصلاً کوکی نمی‌گذارد، بررسی کنید منطق برنامه بعد از تأیید واقعی رمز نشست را تغییر می‌دهد و پاسخ همان برنامه به مرورگر برمی‌گردد. نمونه زیر فقط بخشی از منطق پس از احراز هویت است، نه یک سیستم ورود کامل:
کد / دستور# بعد از تأیید هویت واقعی کاربر:
session["user_id"] = user.id
نباید این خط را بدون بررسی رمز و مجوز به یک مسیر عمومی اضافه کرد. اگر کوکی در پاسخ است ولی مرورگر آن را رد می‌کند، دلیل رد را در مرحله‌های بعد دنبال کنید.
۲. کلید امضای ثابت و محرمانه را بررسی کنید
Flask برای امضای نشست به
SECRET_KEY نیاز دارد. اگر برنامه در هر بار اجرا کلید تازه و تصادفی بسازد، نشست‌های امضاشده با کلید قبلی پس از Restart معتبر نخواهند بود. در چند پردازش نیز استفاده از کلیدهای متفاوت می‌تواند باعث شود یک درخواست موفق و درخواست بعدی خارج‌شده به نظر برسد.کلید باید برای همان محیط اجرا ثابت، قوی و محرمانه باشد و از یک منبع امن مانند متغیر محیطی مدیریت‌شده برنامه خوانده شود. نمونه کلی تنظیم در برنامه:
کد / دستورimport os
app.config["SECRET_KEY"] = os.environ.get("SECRET_KEY")
if not app.config["SECRET_KEY"]:
raise RuntimeError("SECRET_KEY is not configured")
این قطعه باید پس از ساخته‌شدن
app و مطابق ساختار پروژه قرار بگیرد. مقدار واقعی را در کد عمومی، لاگ یا پاسخ HTTP ننویسید. در پنل برنامه پایتون، نام متغیر و وجود مقدار آن را بررسی کنید و مطمئن شوید همه پردازش‌های همان برنامه تنظیم درست را دریافت می‌کنند. بعد از تغییر تنظیمات، برنامه مربوط را در پنل Restart کنید.کلید فعلی یک سایت فعال را برای آزمایش بی‌دلیل عوض نکنید: ممکن است نشست‌های موجود و داده‌های امضاشده قبلی نامعتبر شوند. اگر کلید فاش شده یا واقعاً باید عوض شود، تعویض را با برنامه، آگاهی از خروج کاربران و امکانات نسخه Flask و افزونه‌های پروژه انجام دهید. بعضی قابلیت‌های نگهداری کلید قبلی فقط در نسخه‌های مشخص در دسترس‌اند.
۳. Secure، دامنه و مسیر کوکی را تطبیق دهید
اگر کوکی با ویژگی
کد / دستورSecure تنظیم شده باشد، مرورگر آن را روی اتصال HTTP معمولی ارسال نمی‌کند. مطمئن شوید صفحه ورود و صفحه بعدی هر دو با HTTPS و گواهی معتبر باز می‌شوند. برای برنامه‌ای که فقط از HTTPS استفاده می‌کند، تنظیم امن کوکی می‌تواند چنین باشد:app.config.update(
SESSION_COOKIE_SECURE=True,
SESSION_COOKIE_HTTPONLY=True,
SESSION_COOKIE_SAMESITE="Lax",
)
این مقادیر نمونه‌اند و باید با معماری و نسخه برنامه شما تطبیق داده شوند.
HttpOnly دسترسی معمول JavaScript به کوکی را محدود می‌کند و Lax سیاستی برای بسیاری از نشست‌های هم‌سایتی است. تغییر دادن این گزینه‌ها به مقادیر ضعیف‌تر فقط برای حذف خطا، راه‌حل امنیتی نیست.اگر ورود در
example.com انجام می‌شود و بلافاصله به www.example.com می‌روید، دامنه و محدوده کوکی را در مرورگر مقایسه کنید. اغلب انتخاب یک دامنه اصلی و انتقال درست بقیه نشانی‌ها ساده‌تر است. تنظیم دامنه کوکی برای همه زیردامنه‌ها بدون بررسی، محدوده دسترسی را بیشتر می‌کند. مقدار پیش‌فرض SESSION_COOKIE_DOMAIN و رفتار دقیق را مطابق نسخه Flask خود بررسی کنید؛ در نسخه‌های جدید پیش‌فرض معمولاً کوکی را به همان میزبان محدود می‌کند.برای دیدن مقصد انتقال یک نشانی عمومی، در ترمینال آدرس واقعی خود را جایگزین کنید:
کد / دستورcurl -I https://example.com/
خط
Location در پاسخ انتقال، مقصد را نشان می‌دهد. این فرمان نشست مرورگر و فرآیند ورود را آزمایش نمی‌کند، اما تغییر ناخواسته دامنه یا HTTPS به HTTP را آشکار می‌کند.۴. اگر برنامه پشت پراکسی یا درخواست بین‌دامنه‌ای است
ممکن است HTTPS تا پراکسی برقرار باشد و برنامه پشت آن اجرا شود. اگر برنامه باید از هدرهای پراکسی برای تشخیص آدرس یا طرح اتصال استفاده کند، تعداد پراکسی‌های قابل اعتماد و پاک‌شدن هدرهای ورودی کاربر باید دقیقاً مشخص باشد. ابزار
ProxyFix را با مقادیر حدسی فعال نکنید: اعتماد به هدر جعلی می‌تواند به تشخیص اشتباه مبدأ یا طرح اتصال منجر شود. در هاست اشتراکی، جزئیات پراکسی و امکان دسترسی مستقیم به برنامه را از ارائه‌دهنده بگیرید.اگر صفحه و API واقعاً روی مبدأهای متفاوت‌اند و درخواست با JavaScript ارسال می‌شود، هم ارسال مجاز credentials در مرورگر و هم تنظیم دقیق CORS سرور لازم است. در بعضی طراحی‌های بین‌سایتی،
SameSite=None همراه Secure لازم می‌شود؛ حتی در این صورت مرورگر یا سیاست حریم خصوصی آن ممکن است کوکی شخص ثالث را محدود کند. اجازه‌دادن به همه Originها همراه نشست خصوصی راه‌حل امنی نیست.۵. مدت نشست و نتیجه را آزمایش کنید
اگر مشکل فقط پس از بستن مرورگر رخ می‌دهد، بررسی کنید آیا نشست شما عمداً موقت است یا با تنظیم
session.permanent و مدت انقضای مناسب نگهداری می‌شود. مرورگرها ممکن است نشست‌های مرور قبلی را بازگردانند یا رفتار متفاوتی داشته باشند؛ آزمون را در همان دستگاه و مرورگر هدف انجام دهید. اگر از ذخیره‌ساز سمت سرور استفاده می‌کنید، زمان انقضا و دسترسی آن ذخیره‌ساز را نیز بررسی کنید.پس از هر تغییر، فقط همان برنامه را در پنل Restart کنید، یک نشست تازه با حساب آزمایشی بسازید و مسیر ورود، رفرش، تغییر صفحه و خروج از حساب را امتحان کنید. اگر ورود هنوز نمی‌ماند، زمان دقیق و دلیل رد کوکی یا خطای برنامه را جداگانه بررسی کنید. برای اجرای برنامه‌های سازگار به صفحه هاست پایتون نت‌آرام و برای جزئیات نسخه برنامه به تنظیمات رسمی Flask و راهنمای اعتماد به پراکسی Werkzeug مراجعه کنید.
برچسب‌ها:
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.
مقاله بعدی
دیدگاه‌ها (۰)
دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام