@csrf_exemptiOS アプリがアクセスしている URL (「API エンドポイント」) については、対応するビュー関数で指定して csrf 保護を無効にする必要があります。
詳細はこちら - https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#django.views.decorators.csrf.csrf_exempt
また、セッション認証などの他の認証方法を使用してこれらの URL を保護します。
認証のために、django rest フレームワークと django Tastypie が行ったことを簡単に参照できます。どちらも SessionAuthentication クラスを使用して認証を処理し、iOS アプリが接続できる公開 URL (API エンドポイント) を保護します。
参考文献：-
Django Tastypie には認証クラスもありますが、これを認証と混同しないでください。また、APIKey 認証クラスもあり、django の URL を他のサードパーティの開発者に公開したい場合に役立ちます。サードパーティの開発者は、独自のアプリを構築して、django の URL と通信してデータにアクセスします (「facebook API」と考えてください)。 . 各サードパーティの開発者には、本質的に一意の API を提供できます。APIKeyAuthorization クラスと各サードパーティのアプリに提供される一意の API キーがあるため、「承認された」アプリのみが Django URL を使用できることを確認できます。これは、「Google+」や「Facebook」などのさまざまな大きなプラットフォームがどのように機能するかの本質です。
django の csrf の仕組みの詳細
https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#how-it-works
CSRF 保護は、次のことに基づいています。
他のサイトがアクセスできない、ランダムな値 (いわゆるセッション独立ナンス) に設定された CSRF Cookie。
この Cookie は CsrfViewMiddleware によって設定されます。これは永続的であることを意図していますが、有効期限が切れない Cookie を設定する方法がないため、django.middleware.csrf.get_token() (CSRF トークンを取得するために内部で使用される関数) を呼び出したすべての応答と共に送信されます。 .
すべての送信 POST フォームに存在する「csrfmiddlewaretoken」という名前の非表示のフォーム フィールド。このフィールドの値は、CSRF Cookie の値です。
この部分は template タグによって行われます。
HTTP GET、HEAD、OPTIONS、または TRACE を使用していないすべての着信要求について、CSRF Cookie が存在し、「csrfmiddlewaretoken」フィールドが存在し、正しい必要があります。そうでない場合、ユーザーは 403 エラーを受け取ります。
このチェックは CsrfViewMiddleware によって行われます。
さらに、HTTPS リクエストの場合、CsrfViewMiddleware によって厳密なリファラー チェックが行われます。これは、HTTP 'Set-Cookie' ヘッダーが (残念ながら) 通信しているクライアントによって受け入れられるため、セッションに依存しないナンスを使用するときに HTTPS で発生する可能性のある中間者攻撃に対処するために必要です。 HTTPS の下のサイト。(Referer ヘッダーの存在は HTTP では十分に信頼できないため、HTTP 要求に対しては Referer チェックは行われません。)
これにより、Web サイトから作成されたフォームのみを使用して POST データを戻すことができます。