TFA 2.x introduces a three-layer defense-in-depth security model (Authentication Provider Decoration, user.auth Service Decoration via TfaUserAuth, and a fail-closed backstop on AccountEvents::SET_USER via TfaUserSetSubscriber).
Deploying TFA 2.x to production environments requires careful verification of infrastructure readiness, service decoration integrity, and compatibility with third-party modules (such as SSO/externalauth, simple_oauth, login_destination, mail_login, and masquerade). Misconfigurations, such as applying shared Redis/Memcached backends to cache.tfa_memcache or conflicting hook_form_alter implementations—can result in security risks or unintended HTTP 403 lockouts.
Based on operational checklists and risk analyses prepared by me at Pronovix and reviewed with (ex-)maintainers (@cmlara), there is a clear benefit to publishing these operational verification procedures and technical architectural references directly in the module documentation for developers and coding agents deploying TFA 2.x.
2.x branch.None.
None.
None.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | TFA_PRE_PRODUCTION_VERIFICATION.md | 41.86 KB | mxr576 |
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #2
mxr576Comment #4
mxr576Attached the original document that we produced and then it was split by an a coding-agent (PI Coding Agent + Gemini 3.7 Flash) into multiple documentation pages.
The updated docs site can be reviewed at https://tfa-3621025-3a486e.pages.drupalcode.org/.
Comment #5
cmlaraChiming in to confirm I had previously read TFA_PRE_PRODUCTION_VERIFICATION.md (and commented on earlier drafts). I have not reviewed the MR/the separation of the documentation into individual pages.
To the best of my knowledge TFA_PRE_PRODUCTION_VERIFICATION.md accurately identifies the security structure of of the 2.x branch as it exist at the time of writing. Publishing this resoruce should provide no risk to site owners and would serve to better educate of system integrity needs.
TFA can defend against accidental bypasses however once at the source code level intentional bypass are something it can not fully defend against on its own. Documenting those areas is thus critical to ensure site owners are well educated and understand where other modules are acting beyond their scope.
The review did remind me of previous concerns I had seen of where we could tighten up the infrastructure and as such follow issues were created in the queue to ensure knowledge is transferred to those who step up to fill the role maintaining TFA.. Other areas of the docs already had open issues to embed monitoring inside TFA (TFA should not just trust that its security needs are present it should monitor and report on them as part of a status check).
One could likely take this documentation and turn it into PHPStan rules to help more effectively scan the codebase for threats.