search

firebase / firebase-js-sdk

Firebase Javascript SDK
https://firebase.google.com/docs/web/setup
Other
4.75k stars 872 forks source link

Firebase Auth info is not retained in Safari after 24H #5262

Closed shaibt closed 1 month ago

shaibt commented 2 years ago

[REQUIRED] Describe your environment

[REQUIRED] Describe the problem

Our webapp uses Firebase auth (javascript) anonymous login to create a user uid we can use to identify client instances and apply firestore/database security rules (and perhaps promote them to "full" auth users in the future).

The webapp is a reactJS package that can be added to existing websites and opens inside a child window (iFrame) within a parent window's main webpage - this is a cross domain scenario as the parent is domain A and our app is domain B.

When a user opens the app again in the future we hope that the auth info will be persisted and we can identify the client app as a returning user using the same uid as was created before. In Chrome this is working 100%. In Safari (OSX and iOS Safari 14) this isn't working at all.

It seems that in Safari the auth info is persisted for no more than 24 hours. If the user comes back and reopens the app after a full day (common scenario) auth anon login produces a brand new user and uid as if there was no previously persisted auth token/data.

Assume this somehow has to do with Apple's intelligent privacy mechanisms and/or cross domain limitations and how Firebase auth builds around them (when IndexedDB is not available?) All official docs we could find state that local storage would be deleted once every 7 days assuming no user interactions with the webapp. In our case even in daily use of the app (once a day) we are getting fresh auth uids.

Opening this issue after short consultation with Firebase team here: https://groups.google.com/g/firebase-talk/c/TVpxla9NTgQ/m/tSNwnHUdBgAJ

PS: We do have access to persist data to local storage (or IndexedDB) on the parent window but have no control of when/how firebase auth writes/reads its required persisted data. If indeed the issue is with Apple's privacy protection mechanisms Firebase should provide a hook to let the app handle read/write of persisted data so we could use an alternative method to persist and provide the data when required by the auth API (i.e. using cross domain postMesasge). If Chrome introduces similar measures in the future it will become relevant as well.

PS1: We did not test with non-anon login methods (not relevant in our case) but if the issue is 3rd party local storage / cross domain persistence, these would also not work and would require the user to login at least once day. If persisted data is not retained, it makes Firebase auth practically unusable in 3rd-party/cross-domain scenarios (iFrames).

Steps to reproduce:

Relevant Code:

// TODO(you): code here to reproduce the problem
jbalidiong commented 2 years ago

Thanks for reporting this issue, @shaibt. I'll check this with the Authentication team, and will provide an update. Thanks.

jbalidiong commented 2 years ago

I tried replicating the issue but I wasn't able to replicate the same behavior. The only difference between my code and yours is that I used the version 9.0.0-beta.8 of Firebase and it is not inside an i-frame. Would you mind trying to update the SDK version that you're using and see if the issue persists?

shaibt commented 2 years ago

@jbalidiong I will try to reproduce with the specific version you mentioned. I do think the i-frame element is critical for reproducing this issue as it creates the 3rd-party cross domain behaviours that I sense are at the core of the issue with Safari browsers - as far as I know Firebase uses IndexedDB for persistence of auth info and that is not available when using an embedded i-frame in a cross-domain scenario (as far as I know).

jbalidiong commented 2 years ago

After the discussion with the team, this issue might be due to the implementation of third party cookies blocking or privacy settings in the Safari browser which may affect the indexedDB/localStorage. Please note that we have limited control for this kind of case, but we will try to investigate and see what we can do to improve this behavior. Thanks for the report.

shaibt commented 2 years ago

Hi @jbalidiong. we've built an env with the same SDK version as you requested and running the test to try and reproduce. Because reproducing the issue with high confidence takes at least 24 hours I will report back tomorrow with the results.

shaibt commented 2 years ago

Hi @jbalidiong here's the update after building and testing with version 9.0.0-beta.8: The uid of the anonymous login was indeed retained after 24 hours in Safari (we tested over 2 days with 2 diff devices) so this is different behavior compared to 8.4.2.

I cannot find any comments in the SDK release notes that mention any fixes related to similar auth issues in any of the recent SDK releases. As we cannot use the beta build in our production SW, do you have any recommendations? Is it possible to get info from the dev team on when/where was this issue actually addressed (or something related to it)?

jbalidiong commented 2 years ago

Thanks for the update and sharing the result for the beta version (I'll share this with the team). I noticed that you are using an outdated SDK version, would you mind trying it out with the version 8.9.1 which is the latest for the official release in our document to get the bug fixes and improvements for the previous versions.

shaibt commented 2 years ago

Hi @jbalidiong. I'm happy to report that using SDK 8.9.1 I am not able to reproduce the retention issue in Safari. Is there a way to confirm a fix or modification was done in the auth module that could explain the diff in behavior vs 8.4.2? Hopefully this isn't mere chance. The retention issue was easy to recreate in the older SDK version and I cannot find anything in the release notes that might suggest a fix.

jbalidiong commented 2 years ago

Glad it is working fine using the latest version of Firebase SDK. I’ve checked the release notes and there are no changes or fixes mentioned for Auth and Safari browser. We really appreciate noticing this behavior and confirming that it is not replicable in our latest versions. For future reference, I would recommend testing it out with the latest release if you notice some unusual behavior and if you are using a later version than the current release.

DellaBitta commented 1 month ago

I'm closing this issue but it becasue it appears the original reported behavior has been solved by a newer SDK. If that's not the case then please create a new issue and link this issue to it. Thanks!