Open sannajammeh opened 1 year ago
@marklawlor @EvanBacon any update? seems like an issue that could affect a lot of users of the router -- we are currently having to write work arounds to handle this situation
@aulneau Which workaround are you using?
same here, strips query params
I'm using SDK 50, upgrading from SDK 49 and found similar issues.
I'm navigating using the dropbox API and thus have folder names that contain "(", ")", among other special characters. This seems to be causing a problem in both the path and passed params.
I'm not sure if this is intended behavior and if so, how to work around it.
Thanks
I am currently facing this issue using Microsoft SDK during authentication process. It is stuck in a redirection loop between expo-router web page and redirection URL until SDK is able to use the hash before it is removed:
/mypage#state=ABC1 =>
/mypage =>
microsoft authentication portal =>
/mypage#state=ABC2 =>
/mypage =>
microsoft authentication portal =>
/mypage#state=ABC2 =>
[CAN READ THE HASH]
/mypage
"@expo/metro-runtime": "~3.2.1",
"expo": "~51.0.21",
"expo-router": "~3.5.18",
"expo-web-browser": "~13.0.3",
I am facing the same issue with updated packages:
"@expo/metro-runtime": "~3.2.3",
"expo": "~51.0.31",
"expo-router": "~3.5.23",
"expo-web-browser": "~13.0.3",
Same here, with expo-router versionned from 3.5.19 to 3.5.23 the routing is broken when the anchor tag is used. Also in the context of use of an authentication SDK.
My temporary fix : stay at version 3.5.18 of expo-router.
Other packages :
Which package manager are you using? (Yarn is recommended)
pnpm (known issues due to Metro)
Summary
Supabase Auth and Azure AD B2C both uses callback hashes in the url like so:
origin/path#token=x&refresh_token=y
. V1 of Expo router would keep these intact so that client libraries could strip it from the pathname and serialize them into query parameters that can be used to authenticate.In my app Supabase magic link login is now broken as the hashes are stripped from the pathname. I suspect this also breaks webview oAuth logins that redirect back to the app.
Confirmed this by opening with
uri-scheme open "exp://127.0.0.1:8081/--/(auth)/callback/magiclink#test=true" --ios
.Callback is a catch all route with
[...callback].tsx
inside.pathname
.The affected
expo-router
api's are below:useGlobalSearchParams
->{"callback": "magiclink"}
useLocalSearchParams
->{"callback": ["magiclink"]}
usePathname
->/callback/magiclink
This however, works flawlessly:
On V1 all 3 provide the parameters with the hash.
Minimal reproducible example
Url: https://github.com/sannajammeh/expo-v2-fail
Steps:
expo start --ios
npx uri-scheme open "exp://127.0.0.1:8081/--/(auth)/callback/magiclink#test=true" --ios