完全なeコマースプロジェクト-（11）舞台裏管理プロジェクト（drf）（1）：CORSクロスドメインとJWT

クロスドメインCORS（クロスドメインリソース共有）

バックグラウンド

• django drfフレームワークを使用して、設計背景管理システムを使用します。また、前面と背面に2つの異なるポートがあります。
• フロントエンドとバックエンドは異なるドメイン名であり、データへのクロスドメインアクセスが含まれます。ブラウザの同一生成元ポリシーは、この問題を解決するために、デフォルトで2つの異なるドメイン間のデータへの相互アクセスをサポートしていないため、後ろにある必要があります最後にクロスドメインアクセスのサポートを追加します。

解決

• オプションはリクエストを求めます。これは、データへのクロスドメインアクセスを許可するかどうかを決定するために使用されます。たとえば、バックグラウンド管理にログインします
  

# 登陆操作时的请求

INFO basehttp 124 "OPTIONS /meiduo_admin/authorizations/ HTTP/1.1" 200 0
INFO basehttp 124 "POST /meiduo_admin/authorizations/ HTTP/1.1" 200 227

• django-cors-headers拡張機能を使用する
• 基本的な使用法を知るために作者の文書をチェックしてください

# 1.从pip安装：
python -m pip install django-cors-headers

# 2.然后将其添加到已安装的应用程序中：确保添加结尾逗号，否则可能会收到一个逗号ModuleNotFoundError
INSTALLED_APPS  = [
    ...
    ' corsheaders '，
    ...
]

# 3.您还需要添加一个中间件类来侦听响应：

MIDDLEWARE  = [
    ...
    的corsheaders。中间件。CorsMiddleware '，
     'django.middleware.common.CommonMiddleware'，
    ...
CorsMiddleware应该放置在尽可能高的位置，尤其是在任何可以生成响应的中间件之前，例如Django CommonMiddleware或Whitenoise WhiteNoiseMiddleware。如果不是以前，它将无法将CORS标头添加到这些响应中。

另外，如果您正在使用CORS_REPLACE_HTTPS_REFERER它，则应将其放置在Django之前CsrfViewMiddleware（请参见下文）。

根据中间价你执行顺序，直接放到第一个位置就可以了~
]

ホワイトリストへのアクセスの許可について：CORS_ALLOWED_ORIGINS

授权进行跨站点HTTP请求的来源列表。默认为[]。

Origin由CORS RFC第3.2节定义 为URI方案+主机名+端口，或特殊值“ null”或“ file：//”之一。默认端口（HTTPS = 443，HTTP = 80）在此处是可选的。

浏览器在“隐私敏感的上下文”中（例如，当客户端从file://域中运行时）发送特殊值null 。根据此bug，特殊值file：//是由Android上的某些版本的Chrome意外发送的。

例：

CORS_ALLOWED_ORIGINS  = [
     “ https://example.com”，
     “ https://sub.example.com”，
     “ http：// localhost：8080”，
     “ http://127.0.0.1:9000” 
]
以前，此设置称为CORS_ORIGIN_WHITELIST，仍然可以用作别名，新名称优先。

Cookieへの相互アクセスを許可する：CORS_ALLOW_CREDENTIALS

如果为True，则将允许将cookie包含在跨站点HTTP请求中。默认为False。

注意：在Django 2.1中，添加了SESSION_COOKIE_SAMESITE设置，'Lax'默认情况下设置为 ，这将防止Django的会话cookie跨域发送。更改它以None绕过此安全限制

トークンメカニズム

セッションメカニズムを理解したい場合は、私の前の記事を読むことができます

• トークンメカニズムは、セッションで明らかになったいくつかの欠点を解決するために学習されるため、最初に前の記事を読むことができます

処理する

1.トークンを生成します

• ログインページに入ると、フロントエンドはユーザーが入力したアカウントとパスワードをバックエンドに渡します
• 写真のように事後検証が通過した後、ユーザーデータは暗号化されます（いわゆるトークンが生成されます）が、バックエンドはデータを保存しません！（セッションとの違い）、ただしトークン文字列をフロントエンドに返します

2.フロントエンドはトークン文字列を格納します

• フロントエンドは、バックエンドから返されたトークンデータを受信した後、それを保存します。2つの収納スペースがあります。1つはローカルストレージで、もう1つはセッションストレージです。
  
• フロントエンドは、jsコードを介してローカルストレージにトークン情報を保存するか、抽出することができます。次のように
  
  

3.トークンをリクエストに入れ、検証のためにバックエンドに送信します

• フロントエンドがリクエストを送信するとき、このトークンを取得してバックエンドに送信します
• バックエンドは、フロントエンドから送信されたトークンを復号化します。それを判断する
• プロセス全体のリアエンドには情報は保存されませんが、暗号化されたものを復号化して、データが改ざんされないようにするための正しい検証方法が保存されます。そして、サーバーリソースを節約します。
• 暗号化プロセス中に暗号化の有効期間を設定して、データの有効期限が切れているかどうかを判断することもできます（たとえば、ログインステータスを適時に保存する問題を解決するために、ログイン後7日以内にログインせずにログインできます、およびWebサイトに入ると自動的にログインできます）。

注意

• （1）トークンがストレージに保存された後、ブラウザーは、リクエストを送信するときに、トークンデータを読み取り、それを運び、バックエンドに渡した後、jsコードを介してのみトークンデータを運びたいと考えています。これはcookie（sessionid）と同じではなく、送信されたすべての要求がそれを運びます。

• （2）異なるウェブサイト間で保存されたデータは、jsコードを使用して互いのデータにアクセスすることはできません！つまり、現在のトークンは（上の図のように）現在のドメイン名でストレージスペースに保存され、現在のjsを介してのみ操作できます。

• 現在のjsコードも同じドメイン名の下にあります
  

• （3）上記の操作により、他のWebサイトが現在のドメイン名でデータコンテンツを取得できないようにします。（他のWebサイトがこのWebサイトのデータにアクセスしようとしてjsコードを偽造するのを防ぎます。ドメイン名のセキュリティに基づいて、このドメイン名のjsコードのみにアクセスできます）。つまり、リソースストレージドメイン名（素人の場合はjs、css）とデータストレージドメイン名は同じです。

• （4）暗号化と復号化の方法のセットもあるので、どのサーバーでもトークンデータを検証でき、サーバー拡張の問題を解決します。

上記は、セッションメカニズムの3つの欠点を解決するためのものです。サーバー側のリソーススペースの占有（セッションデータの保存）、csrf攻撃（リクエストが送信されている限りCookieが実行され、情報が漏洩しやすい）、および問題です。クラスター構築の概要（サーバーの拡張）

JWT（Json Web Token）トークンベースの認証メカニズム

基本的なプロセス

• ユーザーはユーザー名とパスワードを使用してサーバーを要求します
• サーバーはユーザーの情報を確認します
• サーバーは検証後にトークンをユーザーに送信します
• クライアントはトークンを保存し、トークン値を各リクエストに添付します
• サーバーはトークン値を検証し、データを返します

jwtの基本構成

• コンプリート：

# JWT 加密后的随机字符串

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

• 合格。3つの部分に分けます。

（1）ヘッダー

• jwtのヘッダーには、次の2つの情報が含まれています。
  • 宣言タイプ、ここにjwtがあります
  • 暗号化を宣言するためのアルゴリズムは、通常、次の
    ようなHMACSHA256の完全なヘッダー情報を直接使用します。

{
    
    
  'typ': 'JWT',
  'alg': 'HS256'
}

次に、ヘッダーはbase64で暗号化され（暗号化は対称的に復号化できます）、最初の部分を形成します

eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9

ペイロード

• ペイロードは有効な情報が格納される場所であり、有効な情報は3つの部分で構成されます

  • 標準に登録された宣言
  • 公式声明
  • プライベートステートメント

• 標準に登録されている宣言（推奨されますが必須ではありません）：

  iss：jwt issuer
  sub：jwtが直面するユーザー
  aud：jwt
  expを受信するパーティ：jwtの有効期限。この有効期限は発行時間よりも長くする必要があります
  。nbf：jwtが使用できなくなるまでの時間を定義します
  。iat：
  jwt jtiの発行時間：jwtの一意のID。主にリプレイ攻撃を回避するための1回限りのトークンとして使用されます。

• パブリックステートメント
  パブリックステートメントは、任意の情報を追加できます。通常、ユーザー関連情報やビジネスに必要なその他の必要な情報を追加できます。ただし、この部分はクライアントで復号化できるため、機密情報を追加することはお勧めしません。

• プライベートステートメント：
  プライベートステートメントは、プロバイダーとコンシューマーが共同で定義するステートメントです。base64は対称的に復号化されるため、機密情報を保存することは一般的に推奨されません。つまり、情報のこの部分はプレーンテキスト情報として分類できます。

ペイロードを定義します。

{
    
    
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

署名

• JWTの3番目の部分はビザ情報であり、このビザ情報は3つの部分で構成されています。

  • ヘッダー（base64の後）
  • ペイロード（base64以降）
  • シークレット
    部分を使用するには、base64暗号化ヘッダーとbase64暗号化ペイロードが必要です。文字列で構成される文字列を接続し、ヘッダーで宣言された暗号化方式を使用してソルトシークレットの組み合わせ暗号化を実行し、jwtの3番目の部分を構成します。 。

署名機能

• データの最初の2つの部分は従来のように暗号化されており、解読後に簡単に変更できるため、データセキュリティは他人によるデータの変更を防ぐことが保証されていますが、署名ビザ情報の機能は反映されています。3番目の部分は後でのみ解読できます。秘密鍵を知っている。最初の2つの情報は私のビザ情報とは異なるので、私はそれを認めず、検証に合格しません。さらに、復号化によって一定期間ログインステータスを維持できます。署名の設定時間。復号化の失敗は、有効期限が原因である可能性があり、その結果、ログインステータスが失われます。

暗号化の紹介

• （1）まず、暗号化アルゴリズムのセットが必要です
• （2）暗号化されたデータが必要です
• （3）暗号化キー：データのセキュリティを確保するため、このキーがないと復号化操作を実行できません。前のQQログインで述べた危険と同様に、秘密鍵も必要です。

さて、最初にここで停止しましょう。これらは基本的な情報です。次のセクションでは、drfでこのjwtを使用する方法を紹介します
。