Closed romaingyh closed 4 months ago
@romaingyh If only the last listener receives the event, wouldn't you be able to just set a listener on your own and that would take over the listener set by Supabaase? Why do you need to explicitly stop the deep link observer set by the supabase_flutter library?
But anyway, here is a PR to finally bring the feature to pause deep link observer. Sorry it took so long.
@romaingyh If only the last listener receives the event, wouldn't you be able to just set a listener on your own and that would take over the listener set by Supabaase? Why do you need to explicitly stop the deep link observer set by the supabase_flutter library?
It was for the initial link, if the app is killed in background and opens from deep link. Even with a second listener, the first one will handle the initial link on init.
But anyway, here is a PR to finally bring the feature to pause deep link observer. Sorry it took so long.
Thanks a lot for this work !
Is your feature request related to a problem? Please describe.
The
authCallbackUrlHostname
was removed sincesupabase_flutter
2.0.0 (#636) but it was the only way to prevent supabase from handling deeplinks, even the ones even those that have nothing to do with Auth.There are already two PR open, including mine, to allow a mix of supabase auth deeplinks and app custom deeplinks #605 #669
Without these PR, the workaround I found in supabase v1 was :
authCallbackUrlHostname: ''
, so the initial link is not handled by supabaseAppLinks allUriStreams
to handle manually deeplinks. I callgetSessionFromUrl
when it's an auth deeplink.Listen to AppLinks stream after supabase init is very important beacause as we discussed before only the last listener will reveive future events
Describe the solution you'd like
Solution can be one of the two PR above but for now just restore
authCallbackUrlHostname
would allow me to migrate to supabase v2Thanks !