<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with gmail]]></title><description><![CDATA[A list of topics that have been tagged with gmail]]></description><link>https://fusionauth.io/community/forum/tags/gmail</link><generator>RSS for Node</generator><lastBuildDate>Wed, 04 Nov 2026 03:19:02 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/gmail.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Why am I receiving two MFA codes during password reset flow?]]></title><description><![CDATA[<p dir="auto">This issue is related to <strong>Gmail's safe-links protection feature</strong>, which scans links in emails for security purposes.</p>
Root Cause
<p dir="auto">When Gmail scans the password reset button/link, it fires <strong>two GET requests</strong> to the /password/change endpoint:</p>

One request from Gmail's link scanner
One request from the actual user click

<p dir="auto">Each request triggers the MFA code generation, resulting in two codes being sent.</p>
Why FusionAuth's Normal Protections May Not Apply
<p dir="auto">FusionAuth has built-in protections against email link scanners consuming codes or triggering duplicate actions. Starting with version 1.49.0, FusionAuth introduced a <strong>mandatory confirmation page</strong> that requires user interaction when a link request doesn't originate from the same browser that initiated the workflow. This prevents most link scanners (including aggressive ones like Outlook Safe Links) from consuming codes.</p>
<p dir="auto">However, this protection may not engage if:</p>

<strong>Custom theme is missing the confirmation template</strong> — If you're using a custom theme, you need to copy the <strong>"Confirmation required"</strong> template (/confirmation-required) into your theme to benefit from this feature. Without it, the protection doesn't work.
The user recently changed their password and has "confirmation trust" already established in their browser
A proxy between the client and FusionAuth is not properly handling cookies that prevent link checker issues
The state parameter is being mangled in a custom theme, causing unexpected behavior

Solutions


<p dir="auto"><strong>Add the Confirmation Required Template to Your Custom Theme</strong> — This is likely the primary fix. The confirmation required template was added in version 1.49.0 and must be manually added to custom themes. Copy it from the default theme to ensure link scanners are blocked from triggering duplicate MFA codes.</p>


<p dir="auto"><strong>Upgrade to the Latest Version</strong> of FusionAuth, which includes the most recent fixes for link scanner issues</p>


<p dir="auto"><strong>Review Custom Theme Modifications</strong> — Compare your theme files against the stock FusionAuth theme to ensure the state parameter and form structure haven't been altered in ways that bypass protections</p>


<p dir="auto"><strong>Check Proxy Configuration</strong> — Ensure any proxy in front of FusionAuth is correctly forwarding cookies and not causing duplicate page renders</p>


<p dir="auto"><strong>Test with Default Theme</strong> — Verify the issue doesn't occur with default templates to isolate whether customizations are the cause (you've already confirmed this resolves the issue)</p>


Why Subsequent Attempts Work
<p dir="auto">After the first password reset attempt, browser state and cookies are properly established, preventing the duplicate request issue on subsequent attempts from the same session.</p>
Why Button vs Link Matters
<p dir="auto">The difference between button and link behavior may be related to how your custom theme implements these elements. Buttons might use different form submission methods or lack the postMethod=true parameter that converts GET requests to POST requests (which link scanners typically don't replicate).</p>

Related Documentation

<a href="https://fusionauth.io/docs/customize/look-and-feel/advanced-themes/template-variables#confirmation-required" rel="nofollow ugc">Confirmation Required Template Variables</a> — Details on the confirmation required template introduced in version 1.49.0
<a href="https://fusionauth.io/blog/announcing-fusionauth-1-49#email-link-workflow-improvements" rel="nofollow ugc">Email Link Workflow Improvements (FusionAuth 1.49)</a> — Explains the confirmation page feature designed to prevent link scanners from consuming codes
<a href="https://fusionauth.io/docs/reference/cookies" rel="nofollow ugc">FusionAuth Cookies Reference</a> — Information about cookies used by FusionAuth's hosted login pages
<a href="https://github.com/FusionAuth/fusionauth-issues/issues/2253" rel="nofollow ugc">GitHub Issue #2253: Email MFA codes sent multiple times during password resets</a> — Related issue about duplicate MFA codes
<a href="https://fusionauth.io/community/forum/topic/2817/password-reset-expired-link-safelinks-users">Community Discussion: Password Reset Expired Link - Safelinks Users</a> — Discussion about link checker issues with password reset flows

]]></description><link>https://fusionauth.io/community/forum/topic/3292/why-am-i-receiving-two-mfa-codes-during-password-reset-flow</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3292/why-am-i-receiving-two-mfa-codes-during-password-reset-flow</guid><dc:creator><![CDATA[FASupportBot]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>