Django-ミドルウェア、CSRF（CSRF）、AUTH認証モジュール

ジャンゴミドルウェア

ミドルウェアとは何ですか？

入るとミドルウェアを通過する必要性を出るときDjangoはガードDjangoのミドルウェアに類似のライフサイクルのフルバージョン、データを要求します

ミドルウェアのはなぜ？

制御ユーザアクセス頻度、グローバル着陸チェック、ホワイトリストへのユーザアクセス、ブラックリスト、等

3つのミドルウェアのビューDjangoのデフォルト

• CSRF
• セッション
• 認証

ミドルウェア（5固定法）を用いて

カスタムミドルウェア

from django.utils.deprecation import MiddlewareMixin


class MyMiddleWare(MiddlewareMixin):
    def process_request(self, request):
        print('我是第一个自定义的中间件的process_request！')
# 写一个路由与视图，启动项目，查看打印结果。
# 再写一个自定义中间件

class MyMiddleWare(MiddlewareMixin):
    def process_request(self, request):
        print('我是第二个自定义的中间件的process_request！')
# 诠释中间件的执行顺序


# 在两个中间件中添加process_response方法。研究中间件消息进出的顺序
class MyMiddleWare(MiddlewareMixin):
    def process_request(self, request):
        print('我是第一个自定义的中间件的process_request！')
    def process_response(self,request，response):
        print('我是第一个自定义的中间件的process_response')
        return response
# 再来研究process_request中直接返回HttpReponse对象，会怎么走接下来的process_response

# process_view,process_exception,process_template_response

カスタムミドルウェア

ミドルウェアは）、すなわち:(主なものは、process一とprocess_responseで、5つのメソッドを定義することができます

• process一（自己、リクエスト）
• process_view（自己、リクエスト、view_func、view_argsと、view_kwargs）
• process_response（自己、リクエスト、レスポンス）

上記方法のリターン値なしHttpResponseオブジェクトとすることがないか、なし、その後、Djangoに定義されたルールに従って継続するバック進行されていない場合はよいのHttpResponseオブジェクト場合、オブジェクトはユーザーに直接戻されます。

process一

process一は一つのパラメータ、要求を有し、要求及びビュー機能は、（前、後のDjangoをルーティングするために、一連の動作でこのリクエストオブジェクト）リクエストと同じです。

要求オブジェクトが同じであるため、私たちは要求を含む、リクエスト・オブジェクトに一連の動作を行うことができる。変数名=変数値、このような動作を、我々は、と同様に、後続の関数で取得し表示することができ私たちミドルウェアに設定された値。

その戻り値はなしのHttpResponseオブジェクトになることはできませんすることができます。戻り値は、それがのHttpResponseオブジェクトである場合、次のミドルウェア処理に行き続けるためになし、その後、通常のプロセスではありません、Djangoのビュー関数は実行されませんし、対応するオブジェクトがブラウザに返されます。

process_response

process_response方法複数のミドルウェアを実行の逆順ミドルウェアに応じて登録され、それは第一のミドルウェアprocess一方法は、最初に実行され、その最終的な実装process_response法、最後の方法ミドルウェア最後process一実行は、そのprocess_responseメソッドが最初に実行されます。

process_view

process_view（自己、リクエスト、view_func、view_argsと、view_kwargs）

この方法は、4つのパラメータが取り

• リクエストはのHttpRequestオブジェクトです。
• view_funcが使用されますDjangoのビュー関数です。（どちらという名の文字列の関数としてよりも、実際にオブジェクトの関数です。）
• view_argsとリストは、ビューパラメータの位置に渡されます。
• view_kwargsは、ビューの辞書のキーパラメータに渡されます。view_argsととview_kwargsは、最初のビューパラメータ（リクエスト）が含まれていません。

Djangoは関数を呼び出す前に、ビューprocess_viewメソッドを呼び出します。

それはNoneまたはHttpResponseオブジェクトを返さねばなりません。それがNoneを返した場合、Djangoはミドルウェアprocess_viewは、任意の他の方法を実行し、要求を処理し続け、その後、対応するビューを実行します。それはHttpResponseオブジェクトを返した場合、Djangoはビューの機能を実行しませんが、ミドルウェアに直接Uターン、フラッシュバックは、1つのprocess_responseの方法を実行し、最後にブラウザに返さ

ミドルウェアの実装プロセス

リクエストがミドルウェアに到着後、各登録された正のシーケンスに従って第一中間process一メソッドの実装は、process一方法は、返される値は、オブジェクト、後者の方法が実行されないprocess一のHttpResponseある場合、それは順次行われ、なしの値を返すが、現在の方法のprocess_response実行はミドルウェアが（すべてではないprocess_response方法がUターンを実行することに留意されたい）、HttpResponseオブジェクトがブラウザに返さ相当します。換言すれば、ミドルウェアは6つのミドルウェア、実装プロセスを登録した場合、最初の三つのミドルウェアはHttpResponseオブジェクト、4,5,6ミドルウェアprocess一及びprocess_response方法が実​​装されていない、3の順序の実装を返します、process_response方法2,1ミドルウェア。

process一方法はprocess_view方法が実行ビューの後、注文と実行のすべてprocess_view方法を継続、Noneを返し、process_view方法ミドルウェアを実行し、ビュー機能は、最初のビューが実行されていない機能を実行する見つけ、一致するルートを実行しています機能。中間体3 process_view方法はのHttpResponseオブジェクト、及び4,5,6 process_view機能のビューを返した場合、最後の中間体から、実行されない、中間process_response方法6は、直接実行を開始する逆です。

CSRF（クロスサイトリクエストフォージェリ）

、シンプルなポスト要求を書き込むには、エラーメッセージを再現します

サイトフィッシング：銀行振込・パスを、あなたも、あなたはあなたがフィッシングサイトでは、お互いのアカウント名と転送量を入力した後も、銀行の言い訳を介してデータを提出し、銀行のページと正確に同じことを、得ることができ、[送信]をクリックします。実際には、内部がフィッシングサイトの他のアカウントのアカウント詐欺の担当者に置き換えられています。トランスファーケースが生じますが、間違ったアカウントを回します

Djangoは二つのプロジェクト、シミュレーション移動現象を開きます

フィッシングサイトとまともなウェブサイトを区別するためにどのように？形で密かに特別な文字列、文字列の変更ページを、対応するバックエンドレコード値、および他のユーザーのポスト要求を送信を形成接続すると、リターンまともなウェブサイトのページでは、私は特別なチェックキャラクタに行ってきました文字列一致

それのこの特定の文字列を書くためにどのように？{％csrf_token％}書き込ま固定テンプレート文法は、フォームは、フォームで書かれなければなりません

ラベルの変更の値、およびすべてのリフレッシュを表示するブラウザ。デモもう一度だけ転送

csrf_tokenを設定する方法AJAX

# 第一种页面上先写一个{%csrf_token%}标签，后面用jquery查找标签取值组成键值对放入data中即可

csrf_token局所使用

# 只想给某个视图韩式加上csrf校验
from django.views.decorators.csrf import csrf_exempt,csrf_protect

# 局部禁用
@csrf_exempt
def index(request):
  pass

# 局部使用
@csrf_protect
def login(request):
  pass

# CBV比较特殊，不能单独加在某个方法上
# 只能加在类上或dispatch方法上
from django.utils.decorators import method_decorator
from django.views.decorators.csrf import csrf_exempt,csrf_protect
@method_decorator(csrf_exempt,name='get')  # 第一种
class Csrf_Token(View):
  @method_decorator(csrf_exempt)  # 第二种
  def dispatch(self,request,*args,**kwargs):
    res = super().dispatch(request,*args,**kwargs)
    return res
  @method_decorator(csrf_exempt)  # 这里这么写不行！！！
  def get(self,request):
    pass
  def post(self,request):
    pass

認証の認証モジュール

我々は、テーブルを構築していない場合でも、二つのコマンドというデータベースの移行を実行する場合、Djangoはまた、テーブルの多くを作成していませんか？あなたはAUTH_USERというテーブルを作成した後、我々はそれがテーブルであるため、それは確かに対応する変更操作テーブル方法があるはずで、内部を見てみましょう

AUTH_USERテーブルのレコードを追加します。

• スーパーユーザを作成します（パスワードは暗号化されているため、手動で挿入されていません）

• 認証証明書を使用するのは簡単

  from django.contrib import auth
  def login(request):
    if request.method == 'POST':
      name = request.POST.get('name')
      pwd = request.POST.get('pwd')
      user = auth.authenticate(request,username=name,password=pwd)
      # 类似于user=models.User.objects.filter(username=name,password=pwd).first()
      if user:
        return redirect('/home/')
    return render(request,'login.html')

• 単に情報を確認していない、あなたはまた、クッキーの前またはセッションで、それが今である、着陸状態のユーザの現在の成功着陸を保存する必要があり、認証にも多くの有用な方法を提供します

  if user:
    # 等价于request.session['name']=name
    auth.login(request,user)  # 登陆，其实就把用户信息放到session中，跑一下验证session表

• 実際にはそのハイライトよりも、上記の認証と着陸、ことを浮き彫りに

  # 只要登陆成功执行了auth.login(request,user)
  # 之后在其他任意的视图函数中都通过request.user获取当前登陆用户对象
  
  # 当没有执行auth.login,request.user打印出来的是匿名用户。将session表数据删除即可演示改效果
  # 如何判断request.user用户是否通过auth.login登陆呢？request.user.is_authenticated
  
  # 为何执行auth.login之后，其他视图函数中就可以通过request.user拿到当前登陆对象呢？想想django的中间件中有没有一个叫Auth啥的中间件，它干了件什么事，能不能推导一下？取出session去表里面查相应的数据，然后放到request.user中，点进去看一下这个中间件确实如此

• ログアウト

  auth.logout(request)
  # 等价于删除session数据request.session.flush()

• 着陸してジャンプするかどうかデコレーターチェック

  from django.contrib.auth.decorators import login_required
  
  @login_required(login_url='/login/',redirect_field_name='old')  # 没登陆会跳转到login页面，并且后面会拼接上你上一次想访问的页面路径/login/?next=/test/,可以通过参数修改next键名
  def my_view(request):
    pass

• すべての機能は、私の見解を飾ると、ログインページにジャンプする必要がある場合は、その後、私はコピーの多くを書く必要があります

  # 可以在配置文件中指定auth校验登陆不合法统一跳转到某个路径
  LOGIN_URL = '/login/'  # 既可以局部配置，也可以全局配置

• 先頭へ戻る我々はAUTH_USERテーブルにデータを追加する方法がありますか？~~~コマンドラインは合理的ではないでしょうか？

  from django.contrib.auth.models import User
  def register(request):
    User.objects.create()  # 不能用这个，因为密码是明文
    User.objects.createuser()  # 创建普通用户
    User.objects.createsuperuser()  # 创建超级用户

• パスワードを確認し、パスワードを変更します

  request.user.check_password(pwd)  # 为什么不直接获取查，因为前端用户输入的是明文数据库密文
  
  request.user.set_password(pwd)
  request.user.save()  # 修改密码

カスタムアプリケーションの認証機能モデルテーブル

AUTH_USERテーブルを拡張するには？

• ワン協会（推奨されません）

  from django.contrib.auth.model s import User
  
  class UserDetail(models.Models):
    phone = models.CharField(max_length=11)
    user = models.OnoToOneField(to=User)

• オブジェクト指向の継承

  from django.contrib.auth.models import User,AbstractUser
  class UserInfo(AbstractUser):
    phone = models.CharField(max_length=32)
  
  # 需要在配置文件中，指定我不再使用默认的auth_user表而是使用我自己创建的Userinfo表
  AUTH_USER_MODEL = "app名.models里面对应的模型表名"
  
  
  """
  自定义认证系统默认使用的数据表之后，我们就可以像使用默认的auth_user表那样使用我们的UserInfo表了。
  库里面也没有auth_user表了，原来auth表的操作方法，现在全部用自定义的表均可实现
  """