前後端分離時の静的ページngix配置プロジェクト

注:以下のすべての内容は実践プロジェクトから来て、すべて自分の総括で、あなたのために使うことができることを望みます!
 
親テストが利用可能:
https://segmentfault.com/a/1190000015378237?utm_source=tag-newest
ドメイン間の解決:
djangoレベルからsettings構成を変更し、ミドルウェアをカスタマイズし、コード

middleware.py  

class MyCors(MiddlewareMixin):
    def process_response(self, request, response):
        response["Access-Control-Allow-Origin"] = "*"
        if request.method == "OPTIONS":
            response["Access-Control-Allow-Headers"] = "Content-Type"
            response["Access-Control-Allow-Methods"] = "DELETE, PUT, POST"
        return response

settings.py  
MIDDLEWARE = [
    '  .middleware.MyCors',
    ...
]

Nginx+uWSDiを使用してDjangoプロジェクトを導入
https://www.cnblogs.com/zzqit/p/10103303.html
前後の分離項目はログインセッションソリューションを共有できません(token判定を使用)
1.tokenによる認証
https://blog.csdn.net/hefeng6500/article/details/86772493
2.jwtによる認証
原理は簡単で、フロントエンドはユーザーの唯一の証明書を伝えて、例えばusername、バックエンドはtoken暗号化を経て、フロントエンドに戻ります(前にこれを研究して多くの穴を踏んだことがあります)
参考資料:http://www.mamicode.com/info-detail-2743993.html
settings.py構成

settings.py  

INSTALLED_APPS = [
    ......,
    'rest_framework',
    'rest_framework.authtoken',  #   token
]
JWT_AUTH = {
    'JWT_EXPIRATION_DELTA': datetime.timedelta(days=1),
    'JWT_AUTH_HEADER_PREFIX': 'JWT',
}

ログインコードdemo

from rest_framework_jwt.settings import api_settings

@api_view(['GET'])
def test_login(request):
    """
    #       
    {

        @example:/user/test_login/
        request:
        return:    json

    }
    """
    demo = 'demo11'
    user = User.objects.create(wx_openid='demo', code=demo, wx_pic=demo, wx_name=demo, sex=1, p_id=0)
    jwt_payload_handler = api_settings.JWT_PAYLOAD_HANDLER
    jwt_encode_handler = api_settings.JWT_ENCODE_HANDLER
    payload = jwt_payload_handler(user)  #   7   ，      
    token = jwt_encode_handler(payload)
    return HttpResponse(
        json.dumps({'status': 1, 'token': token}, ensure_ascii=False, cls=DateEncoder),
        content_type="application/json,charset=utf-8")

ドメイン間でheaders検証パラメータの一部を追加した後のソリューション
https://www.cnblogs.com/scharfsinnig/archive/2017/04/27/6769737.html
例外:
 
djangoはエラーを乗り越えますか?:(corsheaders.E013) Origin '127.0.0.1:8080' in CORS_ORIGIN_WHITELIST is missing schem
https://blog.csdn.net/qq_40423339/article/details/100889120
 
djangoプロジェクトの導入:
Nohup python runserverを使用してdjangoを配備しない
nginxに変更
runserverメソッドはDjangoをデバッグする際によく使われる実行方法で、Djangoが持参した
WSGIサーバは、主にテストと開発で使用され、runserverが開く方法も単一プロセスです.
uWSDIは、WSDIプロトコル、uwsgi、httpなどのプロトコルを実現するWebサーバです.注意uwsgiは通信プロトコルであり、uwsGIはuwsgiプロトコルとWSGIプロトコルを実現するWebサーバである.UWSDIは、超高速なパフォーマンス、低メモリ消費、マルチapp管理などの利点があり、Nginxと組み合わせた
ユーザーアクセスリクエストとアプリケーションappを分離し、本格的な導入を実現できる本番環境です.それに比べて、サポートされる同時性が高く、マルチプロセスの管理が便利で、マルチコアの優位性を発揮し、性能を向上させる.
配置方法は菜鳥チュートリアルを参照してください.
https://www.runoob.com/django/django-nginx-uwsgi.html
https://www.jianshu.com/p/f3fd1f831729
多くの穴を踏んだことがあります.私の構成を参考にしてください.構成は使えます.前にhttpをsocketに書きました.
プロジェクトパス作成m_uwsgi.ini

[uwsgi]
#    
chdir = /code/media_manager
#     application
module = media_manager.wsgi:application
#  nginx   ,     , ，           
;socket=0.0.0.0:8000
#   web    ,      
http = 0.0.0.0:8000
#    
workers = 10
;pidfile=/opt/script/uwsgi.pid
#      
;static-map = /static=/opt/OurBlog/static
;uid = root #  
;gid = root # 
#     
master = true
#    unix Socket pid          
vacuum = true
#    
enable-threads = true
#        ，      
thunder-lock = true
#       
harakiri = 30
#    
;post-buffering = 65536
#      
daemonize = /log/media_manager/m_uwsgi.log
wsgi-file = media_manager/wsgi.py
#      pid  
pidfile = uwsgi.pid
buffer-size = 65536

起動方法uwsgi--ini/プロジェクトパス/m_uwsgi.ini &
nginx構成、nginx後にserverを追加:

server {
        listen       8000;
        server_name  localhost;

        location / {
            include  uwsgi_params;
            uwsgi_pass 127.0.0.1:8000;
            index  index.html index.htm;
            client_max_body_size 35m;
        }
    }