Try expo-router unmatched route as described https://docs.expo.dev/routing/error-handling/ and check the path name and if it matches firebaseauthlink redirect back see code sample below.

function UnmatchedScreen(props: UnmatchedProps) {
    const param = useGlobalSearchParams();

    if (param.unmatched === 'firebaseauth,link') {
        return <Redirect href="../" />;
    }

    return (
        <View>
            <Text>404</Text>
       </View>
    );
}

Running into the same issue!

Anyone know why it's redirecting to a deep link? Is it possible to change it?

Same, can't find any document to customize this behavior

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

Still waiting for reply 🙏🏻

Having this exact same issue, don't close the issue

Same here.

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

Still waiting for reply

I'm running into the same issue. Seems to originate from the recaptcha triggered by firebase authentication that tries to redirect to app-schema://firebaseauth/link, which the expo-router catches

This is an open source repository, all updates are visible in the form of comments here. The only updates are people asking for updates, no one appears to have the time to investigate and provide more information. If this is impacting you, allocating resources to troubleshoot it in depth is the way to move it forward

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

For Expo v50 with expo-router I had to use the following:

import { Unmatched, Redirect, useGlobalSearchParams } from "expo-router";

export default () => {
    const param = useGlobalSearchParams<{ unmatched: string[] }>();

    if (isFirebaseCallback(param.unmatched)) {
        return <Redirect href="/auth/sign-in" />;
    }

    return <Unmatched />;
};

const isFirebaseCallback = (unmatched: string[] | undefined) => {
    return (
        unmatched?.length === 2 &&
        unmatched[0] === "firebaseauth" &&
        unmatched[1] === "link"
    );
};

I have the same issue.

Can we please reopen this issue? I was able to use @micaeldias 's code, but it doesn't keep the state of that screen. How can we keep the local state?

Sure, can reopen. Please note this is an open source repository. If this is important to you, devoting resources to finding the root cause and proposing a PR is the way to get it fixed

for those who have the same problem you just need to create a route for /firebaseauth/link.js that route should be found. that's where we put the OTP screen afterwards

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

Hey @2n2n How do you maintain the state of your app? The confirmation is in state and it got lost

@al3xstathis while I could not replicate @2n2n's Solution, I found another that seemed to solve the problem for me. Instead of handling the OTP on /firebaseauth/link.js I just redirect backwards from that page and keep my otp on the login screen like such:

import { router } from "expo-router";
import React, { useEffect } from "react";
import { View } from "react-native";

export default function FirebaseauthLinkPage() {
  
  useEffect(() => {
    router.back();
  }, []);

  return (
    <View>
    </View>
  );
}

For me when I return to the login screen of my app the state is still lost has anyone found a solution that works since?

State must not be lost since screen is still exiting in route stack

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

This isn't a bug, it's a way for Firebase Auth to send the user back to the app post recaptcha completion. You can customise the URL if you prefer it to have a different value:

It's something like this:

<key>CFBundleURLTypes</key>
<array>
    <dict>
        <key>CFBundleURLName</key>
        <string>com.yourapp.app</string>
        <key>CFBundleURLSchemes</key>
        <array>
            <string>yourcustomscheme</string>
        </array>
    </dict>
</array>

either way, you'll have to handle the URL in your expo navigation once the deeplink redirects to your app after recaptcha. There is nothing to fix from RNFB side. There are a number of suggestions already in this thread that covers ways to handle this. Labelling as a documentation issue.

SOLUTION FOUND !! AT [https://docs.expo.dev/router/error-handling/] just create a new file called +not-found.tsx at inside app. app/+not-found.tsx and inside it only have import { Unmatched } from "expo-router";
export default Unmatched;
So by default no 404 pages will be shown. Do lemme know if it helps. Cheers

It's frustrating not being able to set the redirect route after solving the captcha. I didn't expect that I might have to redirect it through a hack. I've been working on this issue for a few hours now. To be honest, I thought this would be easily resolved.

For now, I'll implement a similar solution. Here's what I did:

I made a small change to my not-found page so that it redirects back directly without actually accessing the missing page.

import { View, Text } from "react-native";
import React, { useEffect } from "react";
import { usePathname, useRouter } from "expo-router";

export default function NotFound() {
  const pathname = usePathname();
  const router = useRouter();
  useEffect(() => {
    if (pathname == "/firebaseauth/link") router.back();
  }, [pathname]);

  return (
    <View>
      <Text>not_found</Text>
    </View>
  );
}

For now, I'll implement a similar solution. Here's what I did:

I made a small change to my not-found page so that it redirects back directly without actually accessing the missing page.

import { View, Text } from "react-native";
import React, { useEffect } from "react";
import { usePathname, useRouter } from "expo-router";

export default function NotFound() {
  const pathname = usePathname();
  const router = useRouter();
  useEffect(() => {
    if (pathname == "/firebaseauth/link") router.back();
  }, [pathname]);

  return (
    <View>
      <Text>not_found</Text>
    </View>
  );
}

Worked like a charm thank you!

Hello 👋, to help manage issues we automatically close stale issues.

This issue has been automatically marked as stale because it has not had activity for quite some time.Has this issue been fixed, or does it still require attention?

This issue will be closed in 15 days if no further activity occurs.

Thank you for your contributions.

Is there any update about this issue ?

Same issue, any proper resolution. I cannot pass the confirmation back to the original view.

This isnt working for me as the param.unmatched comes as undefined.
I am not sure if moving every undefined path to login screen is a good idea.

function UnmatchedScreen(props: UnmatchedProps) {
    const param = useGlobalSearchParams();

    if (param.unmatched === 'firebaseauth,link') {
        return <Redirect href="../" />;
    }

    return (
        <View>
            <Text>404</Text>
       </View>
    );
}

for those who have the same problem you just need to create a route for /firebaseauth/link.js that route should be found. that's where we put the OTP screen afterwards

This worked on iOS emulator, but I am not sure how to work with routing if recaptcha is not asked.
via the official docs

When silent push notifications are properly configured, only a very small percentage of users will experience the reCAPTCHA flow.

PS: this hack is not required with React Navigation (i.e. not using expo router)

I spent a few hours looking into this and believe I've identified the root cause, along with a fix that's principled and robust. (I've tried the other solutions in this thread, like adding a route /firebaseauth/link that invokes router.back(), but while that did go back to my phone auth screen, the component was unmounted and remounted, so the component's state was reset.)

The root cause of this is a bad interaction between a feature in the Firebase iOS SDK and one in Expo Router:

• Firebase uses a technique called "swizzling" to automatically intercept the openURL call and do its business, but then it also passes along the same openURL call to our application so we can handle it too.
• Our iOS app's AppDelegate is supposed to return TRUE if it can handle the provided URL, and FALSE if it can't.
• When using Expo Router, our AppDelegate is configured to just pass the URL along onto the router.
• However, Expo Router always answers "yes I can handle this URL" -- even if it's going to "handle" it by displaying a "Not Found" error.

This interacts badly because it's effectively like Expo Router is hijacking the call that's intended for Firebase Auth. Yet, this situation only occurs because Firebase Auth is forwarding the openURL call to our app even after it has already handled it.

Proposed solution: update your AppDelegate's openURL method to not handle URLs for the hostname "firebaseauth", under the assumption that it's already being handled by Firebase. Put the following into a file called fire-auth-url-fix.patch then cd ios/MyApp and run patch -p1 < fire-auth-url-fix.patch

diff --git a/AppDelegate.mm b/AppDelegate.mm
index 67adadf..9577f68 100644
--- a/AppDelegate.mm
+++ b/AppDelegate.mm
@@ -36,6 +36,10 @@ - (NSURL *)bundleURL

 // Linking API
 - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
+  if ([url.host caseInsensitiveCompare:@"firebaseauth"] == NSOrderedSame) {
+    // invocations for Firebase Auth are handled elsewhere and should not be forwarded to Expo Router
+    return NO;
+  }
   return [super application:application openURL:url options:options] || [RCTLinkingManager application:application openURL:url options:options];
 }

While a more pedantic and precise solution would be to reject all URLs with a scheme that's intended for Firebase, those values are different for each Firebase project, so harder to create a universally applicable patch. The above patch will work as long as you aren't needing to handle URLs for a host called "firebaseauth".

Ideally this would be integrated into the @react-native-firebase/auth plugin.

@jey that's fantastic investigation! I think you may have nailed it

Ideally this would be integrated into the @react-native-firebase/auth plugin.

I agree, and would happily merge any related PR that did that. Unfortunately I think it would be a plugin addition of the "unsafe edit" variety, in Expo plugin terms since it needs to directly modify AppDelegate logic and perhaps I'm wrong but I'm not aware of any expo plugin APIs that allow that cleanly. Still, pretty important. Maybe a separate "auth-plus-expo-router" plugin instead of the main one? Or a config entry or something that only turns on that edit as needed

Alternatively, could just be a documentation edit on whatever page makes sense on rnfirebase.io? (there's an edit button at top right of every page)

Either way I've edited the title of this issue to better reflect the cause / symptom for people searching

@mikehardy I've submitted PR #8203 with an Expo plugin implementing this fix and believe it's ready for review. BTW, thanks for the encouragement and feedback! I "should" have been focusing on an deadline, but along the way this bug got stuck in my craw and really irritated me to look for a fix and create an easy onramp to save others from the same pain and trouble.

Proposed solution: update your AppDelegate's openURL method to not handle URLs for the hostname "firebaseauth", under the assumption that it's already being handled by Firebase. Put the following into a file called fire-auth-url-fix.patch then cd ios/MyApp and run patch -p1 < fire-auth-url-fix.patch

diff --git a/AppDelegate.mm b/AppDelegate.mm
index 67adadf..9577f68 100644
--- a/AppDelegate.mm
+++ b/AppDelegate.mm
@@ -36,6 +36,10 @@ - (NSURL *)bundleURL

 // Linking API
 - (BOOL)application:(UIApplication *)application openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenURLOptionsKey,id> *)options {
+  if ([url.host caseInsensitiveCompare:@"firebaseauth"] == NSOrderedSame) {
+    // invocations for Firebase Auth are handled elsewhere and should not be forwarded to Expo Router
+    return NO;
+  }
   return [super application:application openURL:url options:options] || [RCTLinkingManager application:application openURL:url options:options];
 }

Fantastic explanation. That you for all your hard work on that. I did try this fix, but it's still redirecting after stopping and restarting expo after applying the patch. Any recommendations?

@mcewball13,

I did try this fix, but it's still redirecting after stopping and restarting expo after applying the patch. Any recommendations?

Bummer to hear that. You might have better luck with the branch in #8203 which automates this process with error checking. Note that you'll have to run yarn && yarn lerna:prepare if you want to install directly from that branch.

But, aside from that here are some specific debugging questions:

• Are you sure you're running the iOS build of your app, and not using Expo Go? The iOS build is started with expo run:ios instead of the usual expo start --ios command.
• Can you provide a minimal reproducible example with the patch applied which demonstrates this behavior?