firebaseui-web: Firebase UI does not work with Safari on Mac or iPhone. Recent regression.
- Operating System version: MacOS 13 or iOS 16
- Browser version: Safari 16.1
- Firebase UI version: Latest
- Firebase SDK version: Latest
[REQUIRED] Describe the problem
Firebase UI does not work with Safari on Mac or iPhone.
Steps to reproduce:
- Go to https://fir-ui-demo-84a6c.firebaseapp.com/. This is the project’s own login demo page.
- Try to log in on Mac or iPhone.
- Login hangs.
Additionally: these steps work fine with Chrome on the same Mac.
Relevant Code:
N/A
Seen in console:
TypeError: Right side of assignment cannot be destructured
async onAuthEvent(event: AuthEvent): Promise<void> {
// this line
const { urlResponse, sessionId, postBody, tenantId, error, type } = event;
if (error) {
this.reject(error);
return;
}
The event it is receiving seems to be a window Message event, and not the JSON contained within data
which is what contains the fields to be destructured.
About this issue
- Original URL
- State: closed
- Created 2 years ago
- Reactions: 11
- Comments: 17
Want to clarify that there are 2 different issues here:
This happens in the firebase ui demo - https://fir-ui-demo-84a6c.firebaseapp.com/ on Safari 16.0+. In this case, the app is in the same domain as the oauth handler (which shows up as “https://fir-ui-demo-84a6c.firebaseapp.com/__auth/handler”)
This issue happens when the app is hosted in a different domain than <project>.firebaseapp.com. The Oauth handler is accessed at <project>.firebaseapp.com, so when performing a signin with redirect the flow is like this:
app domain -> <project>.firebaseapp.com/__auth/handler -> IDP page (example - accounts.google.com) -> back to <project]>.firebaseapp.com/__auth/handler with IDP response -> put response in browser storage and go back to app domain -> cross origin iframe to read the IDP response that was put into browser storage, to complete sign in.
This cross-domain browser storage access which is failing likely due to Safari ITP feature. The workarounds in https://github.com/firebase/firebase-js-sdk/issues/6443#issuecomment-1187798276 apply to this issue. As mentioned above, this issue is tracked in https://github.com/firebase/firebase-js-sdk/issues/6716 since it is not specific to ui-web.
This current github issue is tracking scenario 1. I am able to repro this error if I deploy the UI web demo using the CDN, but if I build it using npm, there is no error.
Will dig into this some more.
It would be really nice if someone from the Firebase team could respond here. This is now impacting everyone who upgrades to iOS 16.1 and MacOS Ventura, and I expect it will eventually trickle down to users on older OS versions as well. The only option we have at the moment is apparently just to rip out
firebaseui-web
and write our own auth layer, which isn’t exactly ideal.This appears to work for our web app. However, our mobile application utilizes a webview and unfortunately the popup required for this solution does not work. Still hoping for some action/input by the Firebase team. @firebase-ops , @bojeil-google , @jamesdaniels ?
Thanks @prameshj! I can confirm I’m not seeing issue #1 anymore, neither on desktop Safari 16.1 nor iPadOS Safari 16.1.1. Also, I was able to fix issue #2 by following the official mitigation #3. So all seems good now, with these fixes.
I can also confirm the same, although using mitigation nr1! Thank you @prameshj!! 🎉
Our team switched to the
popup
sign-in workflow and this effectively solved our issue. It’s not a fix per se, but a viable workaround for some until the regression is addressed.Our team was unable to log into the firebaseui demo using either
redirect
orpopup
workflows, yet the popup workflow still worked just fine within our own app. So don’t rule it out until you try the workaround yourself.I ended up stripping firebase ui out and building my own ui using my existing ui framework (vue/vuetify).
The oauth callback process going redirecting to some random firebase page before redirecting back to the app, iframe intercommuncation, etc, seems unnecessarily complex and fragile. I’m not sure how much of this is due to firebase-js vs firebase-ui.
In any case, it’s easy to build the callback urls per platform, which is what I did. Then, covert the tokens into credentials using firebase-js in the callback page, roughly:
This lets me continue using my existing firebase ids, to which my app is currently tied, but also provides me an offramp from firebase itself, as I now am collecting and mapping the native oauth provider ids.