Auth state observer in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when Firebase auth state changes?

Consider the Firebase auth state observer below. What will be logged when a user signs out?

firebase.auth().onAuthStateChanged(user => {
  if (user) {
    console.log('User signed in:', user.uid);
  } else {
    console.log('No user signed in');
  }
});

Firebase

firebase.auth().onAuthStateChanged(user => {
  if (user) {
    console.log('User signed in:', user.uid);
  } else {
    console.log('No user signed in');
  }
});

A Logs 'No user signed in'

B Logs 'User signed in:' followed by the user ID

C Throws an error because user is undefined

D Does nothing, no logs appear

💡 Hint

Think about what the observer receives when the user signs out.

When a user signs out, the observer receives null as the user parameter, so the else block runs, logging 'No user signed in'.

❓ Configuration

intermediate

Which code correctly unsubscribes from Firebase auth state observer?

You want to stop listening to auth state changes to avoid memory leaks. Which option correctly unsubscribes the observer?

Firebase

const unsubscribe = firebase.auth().onAuthStateChanged(user => {
  console.log(user ? 'Signed in' : 'Signed out');
});

// How to unsubscribe?

A firebase.auth().removeListener('onAuthStateChanged', unsubscribe);

B firebase.auth().offAuthStateChanged(unsubscribe);

C firebase.auth().onAuthStateChanged(null);

D unsubscribe();

💡 Hint

Check the return value of onAuthStateChanged.

The onAuthStateChanged method returns an unsubscribe function. Calling it stops the observer.

❓ Architecture

advanced

Best architecture to handle auth state in a single-page app

You build a single-page app using Firebase auth. Which architecture best ensures UI updates correctly on auth state changes?

A Call <code>onAuthStateChanged</code> inside every component that needs user info

B Call <code>onAuthStateChanged</code> once at app start and update global state accordingly

C Use <code>getCurrentUser()</code> repeatedly on user actions instead of observer

D Reload the page on every auth state change to refresh UI

💡 Hint

Think about performance and consistency of user state.

Registering a single observer at app start centralizes auth state management and avoids multiple listeners or unnecessary reloads.

❓ security

advanced

What security risk arises if auth state observer is not used properly?

If your app does not listen to auth state changes and relies only on initial user info, what risk occurs?

A User credentials get exposed in console logs

B Firebase throws an authentication error immediately

C User might access protected content after signing out until page reload

D App crashes due to missing user object

💡 Hint

Consider what happens if UI does not update after sign out.

Without listening to auth state changes, the app may still show protected content after sign out until refreshed, risking unauthorized access.

🧠 Conceptual

expert

Why does Firebase auth state observer trigger twice on page load?

When your app loads, the onAuthStateChanged observer fires twice: once with null and then with the user object. Why?

A Firebase first emits a default null state before confirming user session asynchronously

B It is a bug in Firebase SDK causing duplicate events

C The observer is registered twice accidentally in code

D Browser caches cause the observer to fire twice

💡 Hint

Think about how Firebase loads user session data.

Firebase initially emits null because it does not know user state yet, then asynchronously loads the session and emits the actual user.