remove use of photoURL to store account type in firebase auth

[clandau]

Goal

We want remove use of the photoURL field in Firebase auth to determine the user's account type. The photoURL field is not intended for this, it currently doesn't check that it's a valid URL when setting it client-side, but it does when using the SDK server-side and by setting it manually (neither work to set the account type to a non-url). We anticipate it not allowing us to set this client-side in the future. Now it's a blocker for seeding Firebase authentication accounts in the emulator suite. It could also be a problem as we add different sign-in methods as it automatically updates in Firebase auth based on the photoURL of that service.
Source: https://stackoverflow.com/a/54140413/10699876

Context

Currently we are setting the photoURL field as the account type, "candidate" or "company", when a user signs up. This determines candidate vs company page routing.

Notes

I will try to change the routing so that we can use the accountType field from the user's Firestore document to determine the account type.

If that won't work, we discussed using a custom claim on the Authentication object.
Link: https://firebase.google.com/docs/auth/admin/custom-claims

Definition of Done

• we no longer set Firebase Auth's photoURL field to store the account type when a new user signs up
• user can navigate to all of their allowed routes
• there are no other instances in the application where the account type is determined by the photoURL field in FB auth

Out of scope

• Related is the FB emulator seeding of sample accounts. That is being handled in a separate issue.

[github-actions]

Thanks so much for submitting an issue! We have received it, will review it soon and follow up.
For our contibution guidelines, please check out our contributors guide.

[clandau]

we most likely do need to use the custom claims, as we can't get the user object from the db without knowing the account type, so it has to be somewhere on auth.
I have the front end working.

but custom claims need to be set server-side. Unless there's some easy way to do this through next, I think the best way to go about this may be a Firebase cloud function.