✅ دوره تخصصی آموزش ویوهای کلاس محور جنگو منتشر شد.
Django Class-based Views in depth
در این دوره، به صورت تخصصی کلاس بیس ویوها رو بررسی می کنیم و با همه attribute ها و متدهاشون و روش Override کردنشون آشنا میشیم.
همچنین با همه Exception های CBVs کامل آشنا میشیم.
✅ پشتیبانی دوره رو هم، مثل همیشه کامل و بدون محدودیت، خودم انجام میدم.
#CBVs #Django #DjangoInDepth
لینک دمو و خرید دوره:
https://www.daneshjooyar.com/django-supplementary-cbvs/

پیکربندی لاگ زدن در جنگو - django logging

در این سری از ویدیوها که به ترفندها و نکته های جنگو میپردازیم، به سراغ لاگ زدن در جنگو رفتیم و کانفیگ ها و شیوه پیکربندی آن را از طریق بررسی و خواندن کد داخلی جنگو، شرح دادیم. در این ویدیو به جای کد نوشتن، بیشتر کد خوندیم که بفهمیم جنگو خودش برای لاگ زدن چگونه کار میکند و ما چگونه میتونیم از آن استفاده کنیم. همچنین امکان django logging را در سرویس های کلودی مانند sentry و APM هم مطرح کردیم. این مفاهیم رو در پروژه مینی ترلو به شکل عملی استفاده میکنیم.


video link: https://youtu.be/LGatKmpL7k8

playlist: https://www.youtube.com/playlist?list=PLJ9zDGwhhsBwdrfdaoOqbYev3_ocuBOfv

#django #logging #microfrontend_ir
〰️〰️〰️〰️〰️
©️ @DjangoEx

🧨 شناخت و پیشگیری از یکی از رخنه (Exploit) های متداول وب اپ‌ها: XSS


📃 به عنوان توسعه‌دهنده وب بهتره سعی کنیم تا کدی که توسعه میدیم تا حدامکان #Secure (امن) باشه و در مقابل رخنه‌ها و حملات ساده و متداول آسیب پذیر (#vulnerable) نباشه (و شانس رخنه رو کم کنیم).

استفاده موفق از آسیب پذیری Cross-site-scripting یا XSS باعث میشه اپ شما کد های مخرب یا ناخواسته #Javascript رو برای دیگر کاربران نمایش بده و اجرا کنه.

🎃 کد جاوا اسکریپ مخرب میتونه:
❕اطلاعات کاربران رو بدزده (یا زمینه‌ساز حملات پیچیده‌تری بشه)
❕فعالیت هایی رو انجام بده که ناخواسته اند و مورد تایید یا نیاز کاربر نیستند.

یکی از مفروضات این مشکل امنیتی اینه که محتوایی که وب سایت یا اپ ما تولید میکنه "قابل اعتماد” است. پس برای پیشگیری اش منطقیه که هرچیزی که ممکنه این "اعتماد" رو خراب کنه مدنظر بگیریم.

⬅️ به صورت خیلی خلاصه،‌ اگر کد شما هر محتوا یا ورودی که از سمت کاربر بیاد رو بدون "تمیز کردن” و بررسی صحت (#Validation) ذخیره کنه یا نمایش بده،‌ این رخنه میتونه براش اتفاق بیفته.

⚔️ به عنوان اولین لایه پیشگیری، در وب فریمورک #Django ، فرض براینه که هرچه که در context برای رندر شدن در اختیارش میگذارید، "ناامن” است و با کمک متد html.escape() همه کاراکتر های html را به معادلشون تبدیل میکنه.
مثلا:
<img src="https://lnkd.in/eE-enrjb"/>
به
&lt;img src=&quot;https://lnkd.in/eUCsnhnx;
تبدیل میشه.

🌪 اما متاسفانه این کافی نیست:
1- این پیشفرض فقط شامل Django template engine میشود، مثلا اگر Angular یا React یا Vue استفاده میکنید،‌ احتمالا شامل این موضوع نیستید.

2- افزونه یا اپ های شخص ثالثی که استفاده میکنیم ممکنه شامل این آسیب پذیری باشند.

3- اگر از ()mark_safe یا همون "Safe string" ها در متدها و #template ها استفاده میکنید،‌ دیگه خروجی شما شامل این تبدیل نمیشه. (پیشنهاد میکنم تاجایی که میتونید از این متدها استفاده نکنید.)

4- بعضی از attr ها یا روش استفاده ما از متغیرها در template، ممکنه شامل این پیشفرض نشوند یا دورش بزنند،
مثلا:
<img src={{ profile_photo_url }}>
میتونه با سواستفاده تبدیل شه به
<”img src=”/img/home-bg.jpg onload=alert(1)>

5- کاراکتر backtick و همینطور دیتایی که با base64 انکود بشه escape نمیشود، در واقع محتوایی که کاراکترهای quote یا html نداشته باشه چیزی برای escape شدن نداره،‌ مثلا:
<script>spinner.minimum = {{ minimum_price }} ;</script>
میتونه تبدیل شه به:
<script>spinner.minimum = 0; alert(1) ;</script>

سعی میکنم در پست دیگه ای، با جزئیات بیشتری روش‌ها و راههایی که میتونیم تا حد ممکن از XSS در اپ Django مان پیشگیری (#mitigate ) کنیم رو جمع آوری کنم و بنویسم.

لینک مقاله اصلی که ازش الهام گرفتم:
https://lnkd.in/erpqQREc

از لینکدین Alireza Amouzadeh
تشکر از @alireza_amouzadeh

لینک:
https://www.linkedin.com/posts/alireza-amouzadeh_xss-exploitation-in-django-applications-activity-6948679390654291968-6_IX?utm_source=linkedin_share&utm_medium=member_desktop_web

#django
#python

Django Lifecycle

این پکیج چیه کاربردش چیه؟

تفاوت اصلی میان Django Lifecycle و سیگنال‌ها (Signals) در Django این است که Django Lifecycle یک رویکرد ساختارمندتر و اصولی‌تر را برای مدیریت چرخه عمر اجزا فراهم می‌کند. با استفاده از Django Lifecycle، شما می‌توانید کدهای مربوط به هر مرحله از چرخه عمر را به صورت مستقیم در کلاس‌های مدل یا دیگر اجزا تعریف کنید و این اجزا را به یک مدل متصل کنید. این اجازه را به شما می‌دهد که کدهای مربوط به هر مرحله را در یک مکان مرتبط و خوانا نگه دارید و از تفکیک بخش‌ها بهره‌مند شوید.

مثالی از این بخش:

به عنوان مثال، فرض کنید که می‌خواهید هر زمان که یک مدل از نوع Post ایجاد یا به‌روزرسانی می‌شود، یک عملیات خاصی انجام دهید. با استفاده از Django Lifecycle، می‌توانید این عملیات را به صورت مستقیم در مدل Post تعریف کنید، به عنوان مثال:

from django.db import models
from django_lifecycle import LifecycleModel, hook

class Post(LifecycleModel):
    title = models.CharField(max_length=100)
    content = models.TextField()

    @hook(BEFORE_UPDATE, when="content", has_changed=True)
    def update_history(cls, old_instance, instance, field_name):
        History.objects.create(
            post=instance,
            old_content=old_instance.content,
            new_content=instance.content
        )


post = Post.objects.create(title="Title", content="Content")


post.content = "Updated Content"
post.save()

در این مثال، یک مدل به نام Post تعریف شده است که از کلاس LifecycleModel ارث‌بری کرده است. با استفاده از دکوراتور hook، یک عملیات update_history برای مدل تعریف شده است. این عملیات هر زمان که محتوای یک نمونه از مدل تغییر می‌کند، یک رکورد جدید به جدول History اضافه می‌کند که تاریخچه تغییرات محتوا را ثبت می‌کند.

اطلاعات بیشتر راجبش:

https://github.com/rsinger86/django-lifecycle

@SEYED_BAX

#python
#django

Generic relations

جنریک ریلیشن در جنگو یک رابطه خاصی است که به شما اجازه می دهد یک رابطه (کلید خارجی) را با هر مدلی که در پروژه جنگویی خود نصب کرده اید برقرار کنید. وقتی شما می خواهید یک سیستمی را پیاده سازی کنید که بتواند با اشیای مختلفی ارتباط برقرار کند. ب
رای مثال، یک سیستم نظر دهی که بتواند نظرات را برای پست ها، پروفایل های کاربری، تصاویر و حتی نظرات دیگر ذخیره کند.

برای استفاده از generic relations در جنگو، شما باید از بسته contenttypes استفاده کنید که به شما اجازه می دهد از مدل ContentType استفاده کنید. این مدل اطلاعاتی درباره مدل های نصب شده در پروژه شما را ذخیره می کند و شما می توانید با استفاده از سه فیلد زیر یک رابطه عمومی با هر مدلی برقرار کنید:

یک فیلد ForeignKey که به مدل ContentType اشاره می کند (معمولا با نام content_type نامگذاری می شود).
یک فیلد PositiveIntegerField که کلید اصلی شیء مرتبط را ذخیره می کند (معمولا با نام object_id نامگذاری می شود).
یک فیلد GenericForeignKey که با استفاده از دو فیلد قبلی یک رابطه با شیء مرتبط ایجاد می کند (معمولا با نام content_object نامگذاری می شود).

مثلا فرض کنید ما یک مدل Comment داریم که می خواهیم بتواند به هر مدلی نظر دهد. ما می توانیم از generic relations برای این منظور استفاده کنیم:

from django.db import models
from django.contrib.contenttypes.fields import GenericForeignKey
from django.contrib.contenttypes.models import ContentType

class Comment(models.Model):
    user = models.ForeignKey(User, on_delete=models.CASCADE)
    text = models.TextField()
    date = models.DateTimeField(auto_now_add=True)
   
    content_type = models.ForeignKey(ContentType, on_delete=models.CASCADE)
    object_id = models.PositiveIntegerField()
    content_object = GenericForeignKey()

خوب حالا اینطور می توانیم برای یک پست نظر ثبت کنیم :

post = Post.objects.get(pk=1) 

comment = Comment.objects.create(user=user, text="Nice post!", content_object=post)

اگر بخواهیم برای هر مدل دیگری هم که داریم مانند دوره آموزشی و مقاله یا هر مدل دیگری می توان از همین طریق نظر ثبت کرد .

@SEYED_BAX

✅مطلبی از لینکدین Mohammad Amin Amjadi در رابطه با pre-commit

هر چقدر حجم کد بیشتر بشه یا تیم بزرگ‌تر
بشه چالش و دغدغه‌ها بیشتر هم میشن و ریوو کردن کد هم خودش به چالشی بزرگ‌تر تبدیل
میشه که روز به روز تایم بیشتری می‌گیره و از طرفی احتمال از قلم افتادن توافق‌ها،
نکات و اصول هم بیشتر میشه.

اینجاست که pre-commit به دادمون میرسه. در این پست در ابتدا سعی می‌کنم برخی از نکات و مواردی که خودم در تیم‌ها سعی می‌کردم رعایت کنم رو مطرح کنم [امیدوارم خودشون مفید و آموزنده باشن] و در نهایت به نحوه ستاپ و نوشتن pre-commit می‌پردازم و اشاره‌ای به pre-push در یه مثال کاربردی و مورد نیاز و همین طور جاب qa می‌کنم.


تعداد اسلایدها خیلی زیاد شد و خیلی نکات قطعا از قلم افتادن و جای بهبود خیلی زیاد هست. ممنون میشم هر سوال و نکته و پیشنهادی داشتین بگین حتما و به اشتراک بذارین که بقیه هم استفاده کنن.


#git #gtilab #pre_commit #pre_push #python #django

طراحی میکروسرویس با جنگو بخش دوم میکروسرویس چیست

میکروسرویس ها روندهای جدید توسعه هستند. امروزه شرکت ها معماری میکروسرویس را برای توسعه پروژه ترجیح می دهند. این یک راه حل بسیار فشرده برای یک پروژه است. مدیریت ماژول را آسان می کند و اجرای پروژه را سریعتر می کند. همچنین به توسعه سریعتر پروژه کمک می کند. این دلایل ذکر شده و بسیاری موارد دیگر باعث تقاضای میکروسرویس می شود.

معرفی میکروسرویس
برای میکروسرویس تعریف خاصی وجود ندارد و ممکن هست هر فرد به شکلی آنرا تعریف کند اما دو تعریف عمده آن به شکل زیر است
۱-میکروسرویس‌ها، سرویس‌های کوچک و مستقلی هستند که باهم کار میکنند
۲-میکروسرویس‌ها معماری سرویس گرا با زمینه‌های محدود هستند،بطور مستقل و با یک جزء دیگر در داخل ارتباط برقرار میکنند، این معماری بسیار خودکار و و سیستم‌های نرم افزاری را تکامل می‌دهد

بیایید ببینیم که آیا از معماری سرویس گرا (SOA) آگاه هستید یا خیر، سپس ماژولار بودن پروژه و ارتباط از طریق پیام را نیز می دانید. اگر از شیوه های DevOps آگاه هستید، در مورد استقرار خودکار نیز می دانید. هر دو بیشتر به رویکرد میکروسرویس نزدیک هستند.


سه اصل مهم در طراحی میکروسرویس‌ها:
۱-از میکروسرویس برای استقرار سیستم‌ها و پروژه‌های بزرگ استفاده کنید: برای تمام مقیاس‌های پروژه استفاده از میکروسرویس اشتباه است، بلکه مناسب پروژه‌های بزرگ است که مدیریت آن چالش برانگیز باشد، اما خود این موضوع هم سردرگم کننده هستش اینکه کدوم پروژه رو کوچیک، متوسط، بزرگ بنامیم، منتها اگر سیستم ما دارای بار بالایی از درخواست کاربر است و نیاز به مقیاس پذیری دارد، میتوانیم رویکرد میکروسرویس رو پیاده سازی کنیم(در حجم تعداد اپ نیز تعداد اپ بالا میتواند به این منزله باشد)

۲-این رویکرد هدف‌محور است: مهم نیست که وقتی با مشکل مواجه می‌شویم، باید از رویکرد میکروسرویس پیروی کنیم. امروزه بسیاری از متخصصان برای توسعه پروژه به این رویکرد اشاره می کنند زیرا هدف آنها تنها ارائه راه حل مشکلات نیست، همچنین برای دید بیشتر و حفظ سهولت در ماژول ها، چنین معماری را در عمل به کار می گیرند.

۳-قابلیت تعویض ماژول ها: در پروژه های توسعه یافته قبلی که با رویکرد میکروسرویس ساخته نشده اند، امکان تغییر هر جزء از پروژه کمتر است. قبل از تغییر سازنده کامپوننت باید در مورد تغییرات برنامه ریزی کند، وابستگی کد خاصی را پیدا کند، در صورت عدم موفقیت کد به هر دلیلی، مراحل بازگشت را فهرست کند و تاثیر کد را مشخص کند. پس از همه، تغییرات نیاز به انجام عملیات تست واحد و سپس آزمایش ادغام با کل محصول دارند


در برخی سناریوها، پروژه ها بسیار پیچیده هستند یا وابستگی‌های حیاتی شدیدی دارند، در چنین شرایطی در مورد مسائل آینده یا افزایش حجم بار، ما مجبوریم به جای تغییر، اجزا را حفظ کنیم، که این بزرگترین ضرر یک رویکرد است

در میکروسرویس ها، کل پروژه را بر اساس ماژول ها به یک جزء‌های کوچک تقسیم می کنیم. بطوری که امکان تکرارپذیری را بر روی هر جزء فراهم می کند که تعمیر و نگهداری پروژه رو راحتتر میکند

اپلیکیشن‌های میکروسرویس دارای بخش‌های مهم زیر هستند:
● به اندازه های کوچک تقسیم می شوند
● برای برقراری ارتباط نیازمند انتقال پیام هستند
● مقید به زمینه‌ها هستند
● توسعه انها بصورت مستقل هستش
● استقرار هر بخش مستقل هست
● متصل به کنترل کننده مرکزی نیستند
● ساخت ها توسط فرآیندهای خودکار مستقر می شوند

به شکل آرمان گرایانه به میکروسرویس‌ها نگاه نکنید و با این تصور که در دنیای واقعی قابل پیاده سازی نیست، اگر تصور میکنید که میکروسرویس‌ها توسط بانک‌ها، سیستم‌های بیمارستانی و هتلی پیاده سازی میشه سخت در اشتباه هستید هیچکدام از میکروسرویس استفاده نمیکنند بلکه بیشتر توسط شرکت‌های فعال در حوزه محتوای جریانی(stream content) مورد استفاده قرار میگیرد، استفاده و پیاده سازی میکروسرویس یک انتخاب فردی هست و محدود به دامنه‌ای نیست، اما هدف از آن دو مورد تمرکززدایی و استقلال می‌باشد

تمرکززدایی:به این معنی است کل کارهای داخلی پروژه شامل اجرای هر ماژول، مدیریت وظایف و جابجایی کامل پروژه دیگر توسط یک سیستم واحد، مدیریت و کنترل نمیشود

استقلال: به این معنی است که به تیم‌های توسعه خود برای تولید نرم افزار ایمان داشته باشیم

مزیت این دو رویکرد این است که تغییرات در نرم افزار آسانتر و سریعتر میشود و امکان تصمیم گیری سریعتر را فراهم میکند


ادامه در وبسایت

لینک وبسایت


چندتا نکته بگم
بخش دوم و سوم کتاب بشدت پربار و پر از تحربه‌هایی هست که در دنیای واقعی با اون سروکار داریم و درکی از مسائل برامون مشخص نبود، من سعی کردم در حد توان بخش‌های مهم رو برسونم

#microservice
#django

@code_crafters

یک نکته درباره primary key داخل #جنگو اینه که شما میتونید برای هر app به شکل خاص primary key خاص خودش رو داشته باشید. مثلا برای یک app از big integer استفاده کنید و برای یکی از UUID این رفتار رو برای هر اپ میتونید به مشخص کردن AppConfig.default_auto_field مشخص کنید. حالا #django این قابلیت رو هم بهتون میده که جدا از انتخاب دونه دونه برای هر اپ یک حالت گلوبال در نظر بگیرید که اگر مخصوص اپ ست نکرده باشید از اون استفاده میکنه که پیش‌فرض خود جنگو BigIntegerField در نظر میگیره و میشه با تغییر دادن DEFAULT_AUTO_FIELD داخل settings.py به شکل گلوبال تغییرش داد

@TorhamDevCH

این توانایی که خود #جنگو بهتون میده ولی از trick دیگه هم میتونید استفاده کنید و اون هم ساختن یک مدل ابسترکت و بقیه مدل‌ها ازش ارث ببرن.
مثال:

from django.db import models 
from uuid import uuid4
  
  
class Base(models.Model): 
    id = models.UUIDField(default=uuid.uuid4, primary_key=True)
  
    class Meta: 
        abstract = True

از اونجایی که اگه داخل مدل #django فیلدی داشته باشید که داخلش primary_key مقدار True داشته باشه جنگو دیگه از اون مقدار دیفالتی که مشخص کردید (هردو حالت دو پیام بالا) استفاده نمیکنه و میاد از این فیلد استفاده میکنه. حالا شما میتونید بقیه مدل‌هاتون رو از این مدل ارث بری کنید و دیگه نگران مقدار id نباشید.

@TorhamDevCH

خب من یک چیز خیلی جالب و در این حال گیج‌کننده درباره ORM #جنگو فهمیدم.

تو پیام قبلی گفتم که کوئری‌های #django دقیقا چه زمانی واقعا اجرا میشن. اما اینجا یک نکته دیگه‌ای هم هست، جنگو نتیجه کوئری‌هارو کش میکنه.

و این خیلیییییییییییی مهمه، یعنی بعضی از جاها که فکر میکنید جنگو قرار دیتابیس هیت کنه هیت نمیکنه و از کش استفاده میکنه و بعضی جاها که فکر میکنید قرار کش استفاده کنه واقعا هیت میکنه. دونستن و فهمیدن این که چه زمانی کش استفاده میکنه چه زمانی نه حدود ۲ ساعت از من زمان گرفت :) ولی تو این پست توضیح میدم چیزی که فهمیدم رو.

اول این قانون تو ذهنتون داشته باشید: هر چیزی که باعث ایجاد یک QuerySet جدید بشه، باعث هیت به دیتابیس خواهد شد اگر اون کوئری اجرا بشه.

به مثال زیر دقت کنید:

users = User.objects.all()
print(users)

if users:
    for u in users:
         print(u)

خب تو این مثال فکر میکنید چندبار دیتابیس توسط جنگو هیت میشه؟ اگه ماجرا کش کردن ندونید ولی ماجرا اینکه چه زمانی واقعا اجرا میشه رو بدونید احتمالا با خودتون میگید ۳ بار داخل این کد جنگو دیتابیس رو هیت میکنه.

اما اگر من بگم فقط دو بار دیتابیس هیت میکنه چی؟

بزارید توضیح بدم. تو خط اول ما صرفا کوئری رو ساختیم و هیچ هیتی به دیتابیس نزدیم. تو خط دوم ما کوئری پرینت کردیم و اینجا اولین هیت به دیتابیس خورده میشه، ولی یک نکته اینجاست وقتی شما یک کوئری رو پرینت میکنید جنگو نمیاد کل کوئری رو اجرا کنه چون منطقی نیست!، مثلا اگر کوئری شما هزارتا خروجی داشته باشه شما اون هزارتا رو که داخل پرینت نمیخایید، در نتیجه جنگو فقط یک بخش از کوئری رو ران میکنه یا به عبارت دیگه از LIMIT استفاده میکنه!. تو این خط هیچ کش کردنی اتفاق نمیوفته(جلوتر میگم چرا)

خط بعدی ما از if استفاده کردیم و اینجا یک هیت دیگه به دیتابیس میخوره اما این‌بار کل کوئری اجرا میشه و اینجاست که جنگو ریزالت کوئری میگیره و داخل کش ذخیره میکنه. تو خط بعدی که اومدیم حلقه زدیم روی کوئری جنگو دیگه نمیاد به دیتابیس درخواست بزنه و از کش استفاده میکنه!

در نتیجه اینجا فقط ۲ بار دیتابیس هیت میخوره.

ادامه داخل پیام بعد...

@TorhamDevCH