Repository navigation
Conversation
Give operational security guidance a canonical home outside the package threat models. Fill signed-flow and configuration gaps and link shared requirements to their detailed topic pages.
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
Documentation build overview
9 files changed ·
|
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 49c73c77a7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| email and username login forms have no provider callback proof: submit them to | ||
| ``social:complete`` using a CSRF-protected POST instead. Do not exempt these | ||
| forms or expose an alternate completion route bypassing validation. |
There was a problem hiding this comment.
The documented social:complete view cannot provide the promised CSRF protection: social_django.views.complete is decorated with @csrf_exempt for every backend, so Django ignores a submitted CSRF token. An application following this advice for the legacy email or username backends therefore remains vulnerable to login CSRF despite appearing correctly configured. Document a separate @csrf_protect completion view for these local forms, or change the integration before recommending this route.
Useful? React with 👍 / 👎.
| Applications requiring login-CSRF or account-linking replay protection must add | ||
| an application-controlled initiation and single-use binding before completing | ||
| the login or association. Preserve the initiating authenticated local user | ||
| through account linking. Serve the application and widget callback over HTTPS. |
There was a problem hiding this comment.
This new requirement conflicts with both canonical callback examples immediately above, which still use http://example.com/complete/telegram/, including the copyable data-auth-url. A user following the setup steps can therefore transmit a replayable signed callback over cleartext despite the security section requiring HTTPS; update both examples to use https://.
Useful? React with 👍 / 👎.
1 participant
Give operational security guidance a canonical home outside the package threat models. Fill signed-flow and configuration gaps and link shared requirements to their detailed topic pages.