だから私はここで何をすべきかを理解しようとしています...iOSからDjangoサーバーへのPOST呼び出しを行っていますが、403エラー（無効なCSRFトークン）が発生し続けます。トークンを返す関数を実装することを考えています（その関数にアクセスするにはログインする必要があります）。次に、トークンをPOST呼び出しに追加します。
さて...それをする意味がわかりませんか？TastyPieを使用していて、必要なログインがAPIKeyである場合、csrfチェックを免除する必要がありますか？
物事を正しく理解するために...CSRFはユーザーセッションごとに生成されますか？したがって、Cookieを使用しない場合、CSRFは必要ありませんか？
人々は通常、iOSでDjangoサーバーをどのように使用し、そのようなPOST呼び出しを行うのですか？
ありがとう！
その通りです。Cookie を使用してセッションを管理しない場合、CSRF 保護は必要ありません。CSRF が機能するのは、セッション Cookie がリクエストに自動的に添付されるためです。アクセストークンはそうではありません。
個人的にこの記事はとても参考になりました。それは間違いなく読む価値があり、おそらくあなたの多くの質問に答えるでしょう.
Tastypie に関しては、 SessionAuthentication を許可します。Tastypie でセッション認証を許可する場合は、ユーザーを CSRF から保護する方法を検討することをお勧めします。他の認証スキームでは、これは必要ないようです。私の知る限り、Dmitry は Tastypie がデフォルトで CSRF を無効にすることについて正しいです。つまり、403 エラーが発生するのは奇妙です。おそらく、何か他のことが起こっているのでしょう。@csrf_exempt でビューをラップしてみてください。
CSRF トークンに関しては、セッション独立ナンスとも呼ばれます。それらは永続的であることを意図していますが、Cookie ではそれが不可能であることはおそらくご存知でしょう。いずれにせよ、これは CSRF Cookie がセッションを通じて存続することを意味します。
そうです、CSRF の目的はブラウザーでのデータの改ざんからユーザーを保護することであるため、この場合はあまり意味がありません。
Tastypie はデフォルトでビューの CSRF を無効にしていると思います。