پایتون - هیوادار

معماری Message Queue

Message Queue مفهومی در زمینه برنامه نویسی Async است. فرض کنید بعد از انجام یک عملیات مثل پرداخت باید یک پیامک یا ایمیل ارسال شود. در این صورت عملیات پرداخت نباید به ارسال ایمیل وابسته باشد. در واقع این عملیات های باید Async باشند. پرداخت انجام میشود و یک Task به اسم ایمیل در صف پرداخت قرار میگیرد که در اولین فرصت ایمیل ارسال شود. در مورد اینکه چرا باید از این معماری استفاده کرد یا مزایا یا معایب آن چیست صحبتی ندارم و میشود در اینترنت این موارد را جست.

اینجا معماری کلی آن را میبینیم که در اینترنت ممکن است مورد مفهومی دیده نشود.

عکس بالا رو ببینید:

اول از همه یک سری Task داریم. مثلا گزارش ماهانه مالی، ارسال ایمیل، تهیه thumbnail از عکس بارگزاری شده و.. اینها مثالهایی از تسک هایی هستند که باید Async انجام بشه. گزارش ماهانه که قراره سر ماه نصب شب آماده بشه که فردا صبح کارمندان ازش استفاده کنن باید مستقل از نرم افزار باشه و به صورت تسکی ماهانه انجام بشه.

این تسک ها توی یک صف قرار میگیرند که به ترتیب انجام شن. این صف رو Rabbit MQ یا Redis براموان فراهم میکنن.

بعد تسک ها به ترتیب به Worker هایی داده میشن. در واقع worker ها این تسک ها رو انجام میدن. توی پایتون از celery استفاده میشه معمولا. خود Task ها هم توابعی هستند که به Celery داده میشن.

بعد از اینکه تسک انجام شد ممکنه بخوایم خروجیش رو نگه داریم معمولا Redis گزینه خوبیه. اگر بخواهیم که به صورتی دایمی داشته باشیم خروجی رو توی یک دیتابیس باید ذخیره کنیم.

گفتیم مثلا اگر پرداخت انجام شد باید ایمیل ارسال بشه. خوب مشخصه توی این مثال بعد از انجام پرداخت تسک ارسال ایمیل فراخوانی میشه. اما بعضی تسک ها خود به خود توی بازه های زمانی خاصی باید انجام بشه. اینجا به Schedualer نیاز داریم. Celery قابلیتی داره به اسم Beat که برنامه ریزی با اون انجام میشه و تسک ها رو خودش triger میکنه.

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

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

def index(request, service=None):
    if 'Referer' not in request.headers.keys():
        return redirect('/home/')
.
.
.

def index(request, service=None):

if 'Referer' not in request.headers.keys():

return redirect('/home/')

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

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

            <span class="d-none d-xl-inline-block ms-1"><b>{{ user.email|split:"@"|first }}</b></span>

1	<span class="d-none d-xl-inline-block ms-1"><b>{{ user.email\|split:"@"\|first }}</b></span>

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

from django import template

register = template.Library()


@register.filter
def split(value, seperator=' '):
    return value.split(seperator)


@register.filter
def first(value):
    return value[0] if value else ''

from django import template

@register.filter

def split(value, seperator=' '):

return value.split(seperator)

@register.filter

def first(value):

return value[0] if value else ''

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

                'com.templatetags.custom_filters',

1	'com.templatetags.custom_filters',

load دیتا در migration

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

from django.db import migrations
import csv
import os
from django.conf import settings

def load_data_from_csv(apps, schema_editor):
    
    NameService = apps.get_model('tanks', 'NameService')  
    csv_file_path = os.path.join(settings.BASE_DIR, 'csv_storage/servicename.csv') 
	
    with open(csv_file_path, newline='', encoding='utf-8') as csvfile:
        reader = csv.DictReader(csvfile)
        data_to_insert = [
            NameService(
                name=row['name'],
                ename=row['ename'],
                pname=row['pname'],
                comment=row['comment']
            )
            for row in reader
        ]

        
        NameService.objects.bulk_create(data_to_insert)

class Migration(migrations.Migration):

    dependencies = [
        ('tanks', '0001_initial'),  
    ]

    operations = [
        migrations.RunPython(load_data_from_csv),
    ]

from django.db import migrations

import csv

import os

from django.conf import settings

def load_data_from_csv(apps, schema_editor):

NameService = apps.get_model('tanks', 'NameService')

csv_file_path = os.path.join(settings.BASE_DIR, 'csv_storage/servicename.csv')

with open(csv_file_path, newline='', encoding='utf-8') as csvfile:

reader = csv.DictReader(csvfile)

data_to_insert = [

NameService(

name=row['name'],

ename=row['ename'],

pname=row['pname'],

comment=row['comment']

)

for row in reader

]

NameService.objects.bulk_create(data_to_insert)

class Migration(migrations.Migration):

dependencies = [

('tanks', '0001_initial'),

]

operations = [

migrations.RunPython(load_data_from_csv),

]

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

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

version: '3.1'

services:
  odoo:
    build:
      context: ./odoo
      dockerfile: Dockerfile
    container_name: odoo17
    ports:
      - "8069:8069"
    volumes:
      - odoo-data:/var/lib/odoo
      - ./odoo/odoo17.conf:/etc/odoo17.conf
      - ./odoo/odoo-custom-addons:/opt/odoo17/odoo-custom-addons
    environment:
      - HOST=odoo17-db
      - USER=odoo17
      - PASSWORD=odoo17
    depends_on:
      - db
    user: "odoo17:odoo17"

  db:
    build:
      context: ./postgres
      dockerfile: Dockerfile
    container_name: odoo17-db
    environment:
      - POSTGRES_USER=odoo17
      - POSTGRES_PASSWORD=odoo17
      - POSTGRES_DB=postgres
    volumes:
      - db-data:/var/lib/postgresql/data

volumes:
  odoo-data:
  db-data:

version: '3.1'

services:

odoo:

build:

context: ./odoo

dockerfile: Dockerfile

container_name: odoo17

ports:

- "8069:8069"

volumes:

- odoo-data:/var/lib/odoo

- ./odoo/odoo17.conf:/etc/odoo17.conf

- ./odoo/odoo-custom-addons:/opt/odoo17/odoo-custom-addons

environment:

- HOST=odoo17-db

- USER=odoo17

- PASSWORD=odoo17

depends_on:

- db

user: "odoo17:odoo17"

db:

build:

context: ./postgres

dockerfile: Dockerfile

container_name: odoo17-db

environment:

- POSTGRES_USER=odoo17

- POSTGRES_PASSWORD=odoo17

- POSTGRES_DB=postgres

volumes:

- db-data:/var/lib/postgresql/data

volumes:

odoo-data:

db-data:

داکرفایل postgress:

FROM library/postgres
COPY init.sql /docker-entrypoint-initdb.d/

1 2	FROM library/postgres COPY init.sql /docker-entrypoint-initdb.d/

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

CREATE USER odoo17 IDENTIFIED BY odoo17;

1	CREATE USER odoo17 IDENTIFIED BY odoo17;

فایل odoo17.conf

[options]
admin_passwd = amir
db_host = odoo17-db
db_port = 5432
db_user = odoo17
db_password = odoo17
addons_path = /opt/odoo17/odoo/addons,/opt/odoo17/odoo-custom-addons
logfile = /var/log/odoo/odoo.log

[options]

admin_passwd = amir

db_host = odoo17-db

db_port = 5432

db_user = odoo17

db_password = odoo17

addons_path = /opt/odoo17/odoo/addons,/opt/odoo17/odoo-custom-addons

logfile = /var/log/odoo/odoo.log

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

# Use an official Python runtime as a parent image
FROM python:3.11-slim

# Set environment variables
ENV LANG=C.UTF-8 LC_ALL=C.UTF-8

# Install required packages and dependencies
RUN apt-get update && apt-get install -y --fix-missing \
    git \
    build-essential \
    wget \
    python3-dev \
    libfreetype6-dev \
    libxml2-dev \
    libzip-dev \
    libldap2-dev \
    libsasl2-dev \
    node-less \
    libjpeg62-turbo-dev \
    zlib1g-dev \
    libpq-dev \
    libxslt1-dev \
    libtiff5-dev \
    libopenjp2-7-dev \
    liblcms2-dev \
    libwebp-dev \
    libharfbuzz-dev \
    libfribidi-dev \
    libxcb1-dev \
    && apt-get clean \
    && rm -rf /var/lib/apt/lists/*

# Create Odoo user and group
RUN groupadd -r odoo17 && useradd -m -d /opt/odoo17 -g odoo17 -s /bin/bash odoo17

# Switch to Odoo user
USER odoo17

# Set working directory
WORKDIR /opt/odoo17

# Clone Odoo source code
RUN git clone --depth 1 --branch 17.0 https://www.github.com/odoo/odoo /opt/odoo17/odoo

# Create and activate a virtual environment, then install dependencies
RUN python3 -m venv odoo-venv && \
    /bin/bash -c "source odoo-venv/bin/activate && pip install wheel && pip install -r /opt/odoo17/odoo/requirements.txt"

# Create custom addons directory
RUN mkdir /opt/odoo17/odoo-custom-addons

# Copy Odoo configuration file
COPY odoo17.conf /etc/odoo17.conf

# Expose Odoo port
EXPOSE 8069

# Define the command to run the Odoo server
CMD ["/opt/odoo17/odoo-venv/bin/python3", "/opt/odoo17/odoo/odoo-bin", "-c", "/etc/odoo17.conf"]

# Use an official Python runtime as a parent image

FROM python:3.11-slim

# Set environment variables

ENV LANG=C.UTF-8 LC_ALL=C.UTF-8

# Install required packages and dependencies

RUN apt-get update && apt-get install -y --fix-missing \

git \

build-essential \

wget \

python3-dev \

libfreetype6-dev \

libxml2-dev \

libzip-dev \

libldap2-dev \

libsasl2-dev \

node-less \

libjpeg62-turbo-dev \

zlib1g-dev \

libpq-dev \

libxslt1-dev \

libtiff5-dev \

libopenjp2-7-dev \

liblcms2-dev \

libwebp-dev \

libharfbuzz-dev \

libfribidi-dev \

libxcb1-dev \

&& apt-get clean \

&& rm -rf /var/lib/apt/lists/*

# Create Odoo user and group

RUN groupadd -r odoo17 && useradd -m -d /opt/odoo17 -g odoo17 -s /bin/bash odoo17

# Switch to Odoo user

USER odoo17

# Set working directory

WORKDIR /opt/odoo17

# Clone Odoo source code

RUN git clone --depth 1 --branch 17.0 https://www.github.com/odoo/odoo /opt/odoo17/odoo

# Create and activate a virtual environment, then install dependencies

RUN python3 -m venv odoo-venv && \

/bin/bash -c "source odoo-venv/bin/activate && pip install wheel && pip install -r /opt/odoo17/odoo/requirements.txt"

# Create custom addons directory

RUN mkdir /opt/odoo17/odoo-custom-addons

# Copy Odoo configuration file

COPY odoo17.conf /etc/odoo17.conf

# Expose Odoo port

EXPOSE 8069

# Define the command to run the Odoo server

CMD ["/opt/odoo17/odoo-venv/bin/python3", "/opt/odoo17/odoo/odoo-bin", "-c", "/etc/odoo17.conf"]

getFOOdisplay یا get_foo_display()

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

DOC_STATUS = (
    (0, "Accepted"),
    (1, "Minor Revision Needed"),
    (2, "Major Revision Needed"),
    (3, "Rejected"),
    (4, "Unknown"),
)



class MyModel ...


status = models.IntegerField("document status", choices=DOC_STATUS, default=2)


.
.
.

DOC_STATUS = (

(0, "Accepted"),

(1, "Minor Revision Needed"),

(2, "Major Revision Needed"),

(3, "Rejected"),

(4, "Unknown"),

)

class MyModel ...

status = models.IntegerField("document status", choices=DOC_STATUS, default=2)

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

status_display = mymodelinstance.get_status_display()

{{get_status_display}}

status_display = mymodelinstance.get_status_display()

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

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

events {
  worker_connections 1024;
}

http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;
  sendfile        on;
  keepalive_timeout  65;
  client_header_timeout 600s;
  client_body_timeout 600s;
  send_timeout 600s;

  # limits the size of the client request body
  client_max_body_size 50M;
  
  # These parameters control the buffer sizes used by NGINX when proxying responses from the upstream (uWSGI). Increasing buffer sizes allows NGINX to handle larger responses without having to offload data to disk
  proxy_buffers 4 256k;
  proxy_buffer_size 256k;
  proxy_busy_buffers_size 256k;
  

  # Increase buffer sizes to handle long URLs
  client_header_buffer_size 512k;
  large_client_header_buffers 4 256k;

  # This is the time NGINX waits for uWSGI
  proxy_connect_timeout 600s;
  proxy_read_timeout 600s;
  proxy_send_timeout 600s;

#  upstream myuwsgi {
#    server myuwsgi:8000;
#  }

  server {
    listen 80;

    location / {
      proxy_pass http://myuwsgi:8000;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
    
    location /ws/ {
      proxy_pass http://daphne:8001;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /static/ {
      alias /static/;
    }
  }
}

events {

worker_connections 1024;

}

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

sendfile on;

keepalive_timeout 65;

client_header_timeout 600s;

client_body_timeout 600s;

send_timeout 600s;

# limits the size of the client request body

client_max_body_size 50M;

# These parameters control the buffer sizes used by NGINX when proxying responses from the upstream (uWSGI). Increasing buffer sizes allows NGINX to handle larger responses without having to offload data to disk

proxy_buffers 4 256k;

proxy_buffer_size 256k;

proxy_busy_buffers_size 256k;

# Increase buffer sizes to handle long URLs

client_header_buffer_size 512k;

large_client_header_buffers 4 256k;

# This is the time NGINX waits for uWSGI

proxy_connect_timeout 600s;

proxy_read_timeout 600s;

proxy_send_timeout 600s;

# upstream myuwsgi {

# server myuwsgi:8000;

# }

server {

listen 80;

location / {

proxy_pass http://myuwsgi:8000;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

location /ws/ {

proxy_pass http://daphne:8001;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

location /static/ {

alias /static/;

}

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

version: '3.8'

services:
    nasim:
        image: myuwsgiproject:latest
        #build:
        #    context: .
        #    dockerfile: Dockerfile
        hostname: uwsgiproject
        container_name: uwsgiproject
        volumes:
            - ./app:/opt/app
            - ./data:/opt/data
        expose:
            - "8000"
        environment:
            - DJANGO_SETTINGS_MODULE=core.settings
        command: >
            uwsgi --http 0.0.0.0:8000 --module core.wsgi:application --master --processes 4 --threads 4 --buffer-size 163840 --http-timeout 300 --harakiri 300
    daphne:
            #image: nasimproject-daphne:latest
        build:
            context: .
            dockerfile: DockerfileDaphne
        hostname: daphne
        container_name: daphne
        volumes:
            - ./app:/opt/app
            - ./data:/opt/data
        expose:
            - "8001"
        environment:
            - DJANGO_SETTINGS_MODULE=core.settings
    nginx:
        image: uwsgiproject-nginx:latest
        #build:
        #    context: .
        #    dockerfile: DockerfileNginx
        hostname: nginx
        container_name: nginx
        ports:
            - "80:80"
        depends_on:
            - nasim
            - daphne
        volumes:
            - ./app/static:/static
            - ./nginx/nginx.conf:/etc/nginx/nginx.conf
    rabbit:
        hostname: rabbit
        container_name: rabbit
        image: rabbitmq:3-management
        environment:
            - RABBITMQ_DEFAULT_USER=
            - RABBITMQ_DEFAULT_PASS=
        ports:
            - "5672:5672"  
            - "15672:15672"
    celery:
        build:
            context: .
            dockerfile: DockerfileCelery
        hostname: celery
        container_name: celery
        volumes:
            - ./app:/opt/app
    beat:
        build:
            context: .
            dockerfile: DockerfileBeat
        hostname: beat
        container_name: beat
        volumes:
            - ./app:/opt/app

version: '3.8'

services:

nasim:

image: myuwsgiproject:latest

#build:

# context: .

# dockerfile: Dockerfile

hostname: uwsgiproject

container_name: uwsgiproject

volumes:

- ./app:/opt/app

- ./data:/opt/data

expose:

- "8000"

environment:

- DJANGO_SETTINGS_MODULE=core.settings

command: >

uwsgi --http 0.0.0.0:8000 --module core.wsgi:application --master --processes 4 --threads 4 --buffer-size 163840 --http-timeout 300 --harakiri 300

daphne:

#image: nasimproject-daphne:latest

build:

context: .

dockerfile: DockerfileDaphne

hostname: daphne

container_name: daphne

volumes:

- ./app:/opt/app

- ./data:/opt/data

expose:

- "8001"

environment:

- DJANGO_SETTINGS_MODULE=core.settings

nginx:

image: uwsgiproject-nginx:latest

#build:

# context: .

# dockerfile: DockerfileNginx

hostname: nginx

container_name: nginx

ports:

- "80:80"

depends_on:

- nasim

- daphne

volumes:

- ./app/static:/static

- ./nginx/nginx.conf:/etc/nginx/nginx.conf

rabbit:

hostname: rabbit

container_name: rabbit

image: rabbitmq:3-management

environment:

- RABBITMQ_DEFAULT_USER=

- RABBITMQ_DEFAULT_PASS=

ports:

- "5672:5672"

- "15672:15672"

celery:

build:

context: .

dockerfile: DockerfileCelery

hostname: celery

container_name: celery

volumes:

- ./app:/opt/app

beat:

build:

context: .

dockerfile: DockerfileBeat

hostname: beat

container_name: beat

volumes:

- ./app:/opt/app

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

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

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

    path('impersonation_list/', views.impersonation_list, name='impersonation_list'),
    path('impersonate_user/<int:user_id>/', views.impersonate_user, name='impersonate_user'),
    path('stop_impersonation/', views.stop_impersonation, name='stop_impersonation'),

path('impersonation_list/', views.impersonation_list, name='impersonation_list'),

path('impersonate_user/<int:user_id>/', views.impersonate_user, name='impersonate_user'),

path('stop_impersonation/', views.stop_impersonation, name='stop_impersonation'),

ویوهای اون

@permission_required('user.custom_feature_login_as')
def impersonate_user(request, user_id):
    user_to_impersonate = User.objects.get(pk=user_id)

    if user_to_impersonate and not user_to_impersonate.is_active:
        messages.error(request, 'کاربر فعال نیست')
        return HttpResponseRedirect(reverse('home'))

    original_user = request.user.id
    login(request, user_to_impersonate)

    request.session['original_user'] = original_user
    request.session['impersonating'] = True
    return redirect(reverse('home'))


def stop_impersonation(request):
    if 'impersonating' not in request.session:
        return HttpResponseRedirect(reverse('home'))

    if 'original_user' in request.session:
        original_user_id = request.session['original_user']
        original_user = User.objects.get(pk=original_user_id)

        logout(request)
        login(request, original_user)

        return redirect(reverse('home'))

    return HttpResponseForbidden()


@permission_required('user.custom_feature_login_as')
def impersonation_list(request):
    users = User.objects.exclude(is_superuser=True).exclude(id=request.user.id)

    if request.method == 'GET':
        return render(request, 'user/impersonation_list.html', {'users': users})

@permission_required('user.custom_feature_login_as')

def impersonate_user(request, user_id):

user_to_impersonate = User.objects.get(pk=user_id)

if user_to_impersonate and not user_to_impersonate.is_active:

messages.error(request, 'کاربر فعال نیست')

return HttpResponseRedirect(reverse('home'))

original_user = request.user.id

request.session['original_user'] = original_user

request.session['impersonating'] = True

return redirect(reverse('home'))

def stop_impersonation(request):

if 'impersonating' not in request.session:

return HttpResponseRedirect(reverse('home'))

if 'original_user' in request.session:

original_user_id = request.session['original_user']

original_user = User.objects.get(pk=original_user_id)

logout(request)

return redirect(reverse('home'))

return HttpResponseForbidden()

@permission_required('user.custom_feature_login_as')

def impersonation_list(request):

users = User.objects.exclude(is_superuser=True).exclude(id=request.user.id)

if request.method == 'GET':

return render(request, 'user/impersonation_list.html', {'users': users})

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

from django.utils.deprecation import MiddlewareMixin


class ImpersonateMiddleware(MiddlewareMixin):

    def process_request(self, request):
        if request.session.get('impersonating', False):
            request.impersonating = True
        else:
            request.impersonating = False

from django.utils.deprecation import MiddlewareMixin

class ImpersonateMiddleware(MiddlewareMixin):

def process_request(self, request):

if request.session.get('impersonating', False):

request.impersonating = True

else:

request.impersonating = False

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

            {% if perms.user.custom_feature_login_as and not request.impersonating %}
                <a class="dropdown-item d-block" href="/user/impersonation_list/"><i class="fas fa-user-secret font-size-16 align-middle me-1"></i>
                    <span>لاگین به عنوان</span></a>
            {% endif %}

            {% if request.impersonating %}
                <a class="dropdown-item d-block" href="/user/stop_impersonation/"><i class="fas fa-user-slash font-size-16 align-middle me-1"></i>
                    <span>خروج از کاربر</span></a>
            {% endif %}

            {% if not request.impersonating %}
                <a class="dropdown-item d-block" href="/user/password-reset/"><i class="bx bx-key font-size-16 align-middle me-1"></i>
                        <span>تغییر رمز عبور</span></a>
                <a class="dropdown-item" href="/user/lock"><i class="bx bx-lock-open font-size-16 align-middle me-1"></i>
                    <span>قفل صفحه</span></a>
                <div class="dropdown-divider"></div>
                <form method="post" action="/user/logout">
                    {% csrf_token %}
                    <button type="submit" class="dropdown-item text-danger">
                        <i class="bx bx-power-off font-size-16 align-middle me-1 text-danger"></i>
                        <span>خروج</span>
                    </button>
                </form>
            {% endif %}

{% if perms.user.custom_feature_login_as and not request.impersonating %}

<span>لاگین به عنوان</span></a>

{% endif %}

{% if request.impersonating %}

<span>خروج از کاربر</span></a>

{% endif %}

{% if not request.impersonating %}

<span>تغییر رمز عبور</span></a>

{% csrf_token %}

</button>

</form>

{% endif %}

کانفیگ uWSGI و Nginx روی Socket

قبلا Nginx و uWSGI رو به صورت زیر اجرا کرده بودم که وقتی طول URL زیاد میشد ارور 502 میگرفتم. ارور رو بررسی که کردم دیدم uWSGI ارور میده. و ماکسیموم طول هدر برابر است با 4096 ولی طول این url بیشتره. Nginx رو به صورت زیر اجرا کرده بودم.

nginx.conf

# nginx/nginx.conf
events {
  worker_connections 1024;
}

http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;
  sendfile        on;
  keepalive_timeout  65;


  # Increase client body buffer and header buffer sizes
  client_max_body_size 10M;  # Increase if necessary
  large_client_header_buffers 4 16k;

  upstream myproject {
    server myproject:8000;
  }

  server {
    listen 80;

    location / {
      proxy_pass http://myproject;
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
	
    location /ws/ {
      proxy_pass http://daphne:8001;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /static/ {
      alias /static/;
    }
  }
}

# nginx/nginx.conf

events {

worker_connections 1024;

}

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

sendfile on;

keepalive_timeout 65;

# Increase client body buffer and header buffer sizes

client_max_body_size 10M; # Increase if necessary

large_client_header_buffers 4 16k;

upstream myproject {

server myproject:8000;

}

server {

listen 80;

location / {

proxy_pass http://myproject;

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

location /ws/ {

proxy_pass http://daphne:8001;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

location /static/ {

alias /static/;

}

و Dockerfile ای که مربوط به uWSGI هست به صورت زیر اجرا شده بود:

CMD ["uwsgi", "--socket", "0.0.0.0:8000", "--module", "core.wsgi:application", "--master", "--processes", "4", "--threads", "4"]

1	CMD ["uwsgi", "--socket", "0.0.0.0:8000", "--module", "core.wsgi:application", "--master", "--processes", "4", "--threads", "4"]

بعد –buffer-size رو بهش اضافه کردم که درست بشه

CMD ["uwsgi", "--socket", "/opt/app/uwsgi.sock", "--chmod-socket=666", "--module", "core.wsgi:application", "--master", "--processes", "4", "--threads", "4", "--buffer-size", "8192"]

1	CMD ["uwsgi", "--socket", "/opt/app/uwsgi.sock", "--chmod-socket=666", "--module", "core.wsgi:application", "--master", "--processes", "4", "--threads", "4", "--buffer-size", "8192"]

اما مشکل حل نشد. مشکل اینجا بود که Nginx به صورت پراکسی کل درخواست http رو به uWSGI میفرسته ولی بهتره که درخواست رو خودش پردازش کنه و بعد روی socket درخواست رو به uWSGI بده چون اون پروتکل wsgi رو بهتر و با پرفورمنس بهتر مدیریت میکنه.

قبلا uWSGI هم درخواست های http رو پردازش میکرد هم به عنوان یک application server درخواست های wsgi رو مدیریت میکرد یعنی Nginx یک reverse proxy معمولی بود ولی بهتره که http رو nginx مدیریت کنه و uWSGI به عنوان application server کار کنه که این از نظر پرفورمنس بهتره.

حالا که uWSGI رو روی socker کانفیگ کردیم باید Nginx هم درخواست ها رو روی socket بگیره و بده. بنابراین تنظیمات جدید به صورت زیر میشه:

events {
  worker_connections 1024;
}

http {
  include       /etc/nginx/mime.types;
  default_type  application/octet-stream;
  sendfile        on;
  keepalive_timeout  65;

  # Increase client body buffer and header buffer sizes
  client_max_body_size 10M;  # Increase if necessary
  large_client_header_buffers 4 16k;

  upstream myproject {
    # Connect to the uWSGI app via Unix socket
    server unix:/opt/app/uwsgi.sock;
  }

  server {
    listen 80;

    location / {
      # Forward requests to uWSGI socket
      uwsgi_pass myproject;
      include /etc/nginx/uwsgi_params;

      # Set proxy headers
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }
    
    location /ws/ {
      # Forward WebSocket requests to Daphne
      proxy_pass http://daphne:8001;
      proxy_http_version 1.1;
      proxy_set_header Upgrade $http_upgrade;
      proxy_set_header Connection "upgrade";
      proxy_set_header Host $host;
      proxy_set_header X-Real-IP $remote_addr;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
    }

    location /static/ {
      alias /static/;
    }
  }
}

events {

worker_connections 1024;

}

http {

include /etc/nginx/mime.types;

default_type application/octet-stream;

sendfile on;

keepalive_timeout 65;

# Increase client body buffer and header buffer sizes

client_max_body_size 10M; # Increase if necessary

large_client_header_buffers 4 16k;

upstream myproject {

# Connect to the uWSGI app via Unix socket

server unix:/opt/app/uwsgi.sock;

}

server {

listen 80;

location / {

# Forward requests to uWSGI socket

uwsgi_pass myproject;

include /etc/nginx/uwsgi_params;

# Set proxy headers

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

location /ws/ {

# Forward WebSocket requests to Daphne

proxy_pass http://daphne:8001;

proxy_http_version 1.1;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection "upgrade";

proxy_set_header Host $host;

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header X-Forwarded-Proto $scheme;

}

location /static/ {

alias /static/;

}

معماری scrapy

عکس زیر معماری و روند کار scrapy را نشان میدهد. روند کار خیلی جالبه

scrapy بخش های زیر رو داره

spiders: در واقع اون کدی هست که ما میزنیم و میخایم با روش خودمون از سایت های مختلف دیتا بگیریم و به روش خودمون ذخیره کنیم. در واقع اون کدی که ما میزنیم توی بخش spider قرار میگیره. مثلا میگیم از فلان سایت این قسمت های صفحه رو بگیر و ذخیره کن

Engine: موتور scrapy که در واقع مدیریت و ارتباطات بین اجزای مختلف رو داره

ITEM PIPELINES: توی این قسمت میگیم که دیتایی که گرفتیم چه بلایی سرش بیاد. مثلا بگیم توی دیتابیس یا فایل ذخیره بشه. تمیز کردن دیتا و صحت سنجیش هم همینجا انجام میشه.

Downloader: وظیفه گرفتن یک صفحه و دادنش به Engine رو داره

Scheduler: درخواست ها رو توی صف میزاره و سر وقتش به جریان میندازه

Downloader middleware: تمامی درخواست های بین Downloader و Engine از این واسط ها رد میشه. میتونه خیلی از درخواست ها رو بلاک کنه میتونه response ای که میگیره رو به Engine نده و با درخواست های بعد جمع کنه یه جا بده. درخواستهایی که جوابش رو داره دیگه نفرسته و هر چیزی رو کنترل کنه

Spider middleware: بین Engin و Spider میشینه درخواست ها رو به Engine میفرسته و جوابش رو به Spider میده از دوباره Item هایی که از Spider میاد رو بر میگردونه و این وسط تغییرات لازم رو انجام میده.

یه درخواست مسیرهای زیر رو میگذرونه توی Spider. عکس بالا یک Spider رو نشون میده.

اول متد start_request یک آبجکت Request رو به callback ای به اسم pars() میفرسته.

pars() اگه لازم باشه درخواست رو به یه callback دیگه میفرسته و درنهایت Response ای که از Downloader میگیره رو به Item تبدیل میکنه به Item pipline میفرسته که توی دیتابیس ذخیره بهشه یا به Feed Exports مفرسته که توی فایل ذخیره بشه