Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v9 modular: firebase getAuth method throwing error if cookies are disabled by browser (no localStorage) #5618

Closed
qlereboursBS opened this issue Oct 14, 2021 · 1 comment · Fixed by #5635

Comments

@qlereboursBS
Copy link

[REQUIRED] Describe your environment

  • Operating System version: Linux - Ubuntu 20.4
  • Browser version: Chrome 94
  • Firebase SDK version: 9.1.1
  • Firebase Product: auth

[REQUIRED] Describe the problem

When cookies are disabled by the browser (which seems to be the case by default in private browsing for third party website, loaded on iframe for instance, then the getAuth throws an error.
It's the same issue that has been reported here #5274 but the given answer isn't convenient.
I really think that in term of developer experience, it shouldn't be our role to check if the localStorage is available and depending on that, have a custom auth initialization, like I had to do here:

let auth;
export const getAuth = (): Auth => {
  if (auth) {
    return auth;
  }

  const hasAccessToLocalStorage = !!getLocalStorage();
  auth = initializeAuth(getApp(), {
    persistence: hasAccessToLocalStorage ? browserLocalPersistence : indexedDBLocalPersistence,
  });
  return auth;
};

If Firebase isn't handling this case, then the getAuth method is useless because we'll always have to check if the localStorage is available.

Steps to reproduce:

  • Create an app with this code sample:
import { getAuth, onAuthStateChanged } from 'firebase/auth';

onAuthStateChanged(getAuth(), (user) => { console.log(user); });
  • Make it run on Chrome with disabled cookies chrome://settings/cookies then "Block all cookies"
  • It should break

Thank you for your time, and sorry if what I suggest isn't possible

@sam-gc
Copy link
Contributor

sam-gc commented Oct 19, 2021

Hi @qlereboursBS, thanks for filing this. This is indeed a bug and the situation described should be handled gracefully (by falling back to in-memory storage). Do note, however, that the library will work in just a very limited capacity in this case---the session will not be persisted on refresh.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
3 participants