Reputation: 47881
I'm trying to work around the lack of a username property in firebase auth, and was thinking of storing a username in the user profile itself in the UserInfo.displayName
property. This is necessary so that I can get the displayname as auth.token.name
in the security rules and then use it as a username.
However, it seems like the updateProfile method isn't locked down so it is conceivable that the user can hack the api with their token and call updateProfile directly to change that display name to someone else's username. https://firebase.google.com/docs/reference/js/firebase.User#updateProfile
Is there a way that I can lock down that displayName so that it's not editable after by the client or after registration?
Upvotes: 4
Views: 930
Reputation: 2545
You can also store the username in a custom claim. Users will not be able to modify it.
Set it on the server (or serverless function, typically triggered after a user document creation in Firestore):
getAuth().setCustomUserClaims(uid, { username: "MonkeyBonkey" })
Get it on the client:
firebase.auth().currentUser.getIdTokenResult()
.then(idTokenResult => console.log(idTokenResult.claims.username))
Upvotes: 0
Reputation: 138834
As Frank van Puffelen mentioned in his answer and as user482594 pointed out in his comment, there is no way you can "lock" FirebaseUser
properties such as displayName
. However, you can add that data into the database and lock it using Firebase Security Rules, as explained below.
Yes there is a way in which you can achieve this using Firebase Security Rules
. You can do this not only for the username but for all the fields that you need. Please see the folowing line of code that you need to add in your security rules at the coresponding level.
".write": "!data.exists() || !newData.exists()"
This means that you can write as long as old data or new data does not exist
. In other words, if data already exists, you cannot write.
Upvotes: 1
Reputation: 598951
firebaser here
There is no way to limit the user profile changes to initial user registration. The public properties in that profile (currently displayName
and photoURL
) are the user's to change.
If you want more control over the properties kept for a user, you will have to keep them in a secondary system, such as the database that Alex mentions in his answer.
Upvotes: 2