Referer در request های وبسایت

در جایی که به اشتباه route ای تعریف شده بود و تغییر آن وسط پروژه مشکل بود شرایط بررسی شد و دیدیم که در شرایطی که کاربر از طریق خود سایت به این صفحه نیاید باید به صفحه home منتقل شود و با این تحلیل مشکل حل شده و نیاز به تغییر route نیست و در اینجا مفهوم Referer مطرح می شود. در صورتی که کاربر از طریق لینکهای خود سایت به صفحات مختلف برود request دارای Referer است اما اگر خودش مستقیما لینک را بزند خارج از چارچوب سایت Referer نداریم بنابراین با کد زیر در view مربوطه مشکل حل شد:

افزودن Template کاستوم توی جنگو

امروز لازم بود که یک فیلتر توی template engine جنگو اضافه کنم که یک ایمیل رو بگیره و بخش قبل از @ رو نشون بده. مثل زیر:

بنابراین یه تمپلیت تعریف کردم. یک فایل به اسم custom_filters.pyt ساختم و کد اون از قرار زیره:

و در نهایت باید به TEMPLATES توی setting.py اضافه بشه:

load دیتا در migration

گاهی پیش میاد که یک سری جدول توی دیتابیس باید همیشه یک دیتای از پیش تعریف شده توش ذخیره بشه. در واقع وقتی جدول رو میسازیم و migrate میکنیم بهتره که بلافاصله دیتای خودمون رو توش ذخیره کنیم. برای این کار توی فایل migration میتونیم operations رو تعریف کنیم و یک تابع رو توش صدا بزنیم مثال زیر همین کار رو کرده و توی اون تابع جدول رو پر میکنه:

پیاده سازی Odoo روی داکر Docker

برای پیاده سازی Odoo توی داکر باید اول docker-compose.yml رو داشته باشیم:

داکرفایل postgress:

یه فایل init.sql هم استفاده شده:

فایل odoo17.conf

از همه مهمتر Dockerfile خود Odoo:

getFOOdisplay یا get_foo_display()

اگر توی یک مدل جنگو از choice استفاده کنیم برای اینکه با اندیس توی template یا توی view به مقدار choice دسترسی پیدا کنیم باید با شورت کات های زیر کار کنیم مثلا برای مدل و فیلد زیر»:

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

سایز هدر و timeout توی پروژه وب

در نرم افزاری طول URL از حدی که بیشتر میشد سرور ارور بر میگردوند. با بررسی لاگ Nginx و uWSIG متوجه شدم که سایز هدری که مرورگر میفرسته از حدی بیشتره و سرور قبول نمیکنه. از طرفی اون عملیات زمان بر هم بود و وقتی که سایز هدر را هم بیشتر کردم باز هم چون طول میکشید سرور کانکشن رو میبست. با تنظیمات Nginx زیر تونستم هم طول هدر رو بیشتر کنم هم مدت زمان کانکشن ها:

فایل compose کل سرویس ها هم مثل زیره:

قابلیت لاگین به عنوان کاربران دیگر در جنگو

برای اینکه ببینیم توی یه پروژه کاربرها با دسترسی های مختلف چطور سایتمون رو میبینن میخایم یه قابلیت به سایت اضافه کنیم که کاربر ادمین بتونه بجای هر کاربری لاگین کنه. login as

برای این کار route های زیر رو اضافه میکنیم:

ویوهای اون

حالا یه middleware مینویسیم و میزاریم آخر بقیه که توی هر request این رو ست کنه:

حالا از اینا توی تمپلیتها استفاده میکنم:

جلوگیری از لاگین همزمان با یک نام کاربری

اگر بخایم یک نام کاربری نتونه همزمان توی دو تا سیستم لاگین کنه باید چیکار کنیم؟ باید یک Middleware بنویسیم که اگر سشن کاربر با سشن ذخیره شده قبلی برابر نبود اون رو پاک کنه و جدید رو بنویسه.

حالا این میدلویر رو باید اضافه کنیم

اگر اون سشنی که پاک شده بعدش بیاد لاگین بزنه به ارور میخوره بنابراین باید این تابع رو یه تغییراتی بدیم

اینکه این کد به درستی کار میکنه کافیه؟

آیا اینکه کد زیر به درستی کار میکنه کافیه؟

تابع بالا به درستی کار میکنه اما با تابع زیر جایگزینش کردم:

توی کد اول از دو فرم استفاده شده اما صرفا جهت رندر شدن توی HTML و از هیچ کدوم از قابلیت های دیگه فرم استفاده نشده. توی فرم هر صحت دیتای هر فیلد بر اساس دیتابیس بررسی میشه و صحت سنجی میشه. هر ارور مرتبطی با کل فرم یا هر کدوم از فیلدها در صورت وجود به کاربر نشون داده میشه. تمامی validation های لازم بعد از صدا زدن تابع is_valid انجام میشه. تمامی این موارد توی کد اول انجام نشده و در کل از فرم جنگو اصلا استفاده نشده. بخاطر همین کد دوم قابل اعتمادتره و قطعا باگهای کمتری دیده خواهد داشت. از طرفی واقعا کد دوم خواناتر و زیباتر هست.

چطور برای دو مدل که با هم ارتباط دارند Form و View بنویسیم

دو فرم که با مدل های آنها با هم ارتباط دارند رو میشه توی یک فرم به شکل زیر ساخت:

view باید به شکل زیر باشه