Email/Password auth provider custom fields
complete
C
Chris Grabosky
The auth providers (especially email/password) should have a native way of extending the client.auth.authInfo object being returned to Stitch Query Anywhere. This will let the developers store the name of the user, and more importantly, things like group membership for use within rules.
Drew DiPalma
complete
We've now released the ability to link data in Atlas cluster to your authentication provider (including Email/Password authentication), enabling custom data for your users.
You can learn more in our documentation: https://docs.mongodb.com/stitch/users/configure-custom-user-data/index.html
Drew DiPalma
in progress
This improvement is now in progress.
Drew DiPalma
planned
We have an upcoming improvement planned in which you will able able to map data from a Atlas collection to a user and then that data will be pulled into the user object on authentication and available in SDKs, Functions, and Rules.
Phillip Malboeuf
Drew DiPalma: very niice!
M
Mauricio Maroto
Hi Chris Grabosky I once asked something similar to MongoDB. Let me copy that for you, in case it is useful to you:
QUESTION: "Hi me again, how are you doing? I hope great.
So after authenticating a given user through email/password credentials with Stitch, you know by calling the loginWithCredential method using the auth property of a default initialized stitch client instance, then async-ly or Promise-ly, I'll get a response back with authenticated StitchUser for that particular StitchAppClient (which, according to docs, would be persisted beyond the lifetime of a browser session).
So far so good. ok.
Then, I noticed that inside this auth-ed StitchUser response, there is a property called profile. Inside, it shows other properties like birthday, email, firstName, gender, and so on. The only field already populated is email, the user's email. According to the docs, this is a StitchUserProfile interface object and it is "The set of properties that describe a MongoDB Stitch user."
Question 1: How do I set fields for this profile properties. I tried overriding them like response.profile.gender = 'male' but it fails.
Question 2: Why is the email property already filled (with the user's email) and nothing else?
Thanks."
ANSWER:
"Question 1:
As the StitchProfile is a JSON object you can add fields after it is copied to a local variable:
const client = stitch.Stitch.initializeDefaultAppClient('application-id');
const credential = new stitch.UserPasswordCredential("username", "password");
client.auth.loginWithCredential(credential)
.then(authedId => {
authedId.profile.data.gender = 'male';
var profile = JSON.stringify(authedId.profile);
console.log(
successfully logged in with id: ${profile}
)})
.catch(err => console.error(
login failed with error: ${err}
));As this change is specific to this local variable the property will not be set globally for this user. As per the Stitch Users documentation for each authenticated user of your application, a Stitch user object is created that contains metadata about that user. Stitch encrypts the user data and stores it securely. You can access the user object from:
Stitch functions with the context.user variable
Stitch rules with the %%user object
Client code via the SDKs using StitchProfile
Question 2:
As per the Stitch user documentation mentioned earlier, when using the Google or Facebook authentication provider, the data field contains the metadata associated with the user. The following sub-fields are provided by the authentication provider:
name
email
picture
first_name
last_name
gender
birthday
min_age
max_age
The min_age and max_age fields are only provided by the Google authentication provider if you explicitly enable the Google+ APIs.
So these values are set based on the authentication provider used. The email/password authentication provider should only set the email property."
Does this make sense to you?
Let me know your thoguhts.
Best,
Mauricio M.
C
Chris Grabosky
Mauricio Maroto: Thanks. Yea, basically I would like a stitch function to update that object. When you write to it locally, it will not persist. I want that to be sent back and stored (like it does for the Google/Facebook ones). Similarly, i want to extend it with like a "user group" which cannot be modified by the user (to prevent getting access to data) so I can use the Rules engine to restrict by another field common to multiple users rather than storing an array of every User ID.
The current mechanism is to use a trigger to create a
user
collection to store this data, then query anywhere and rules to get the document. Then you could merge it client-side like you mentioned. Just would be easier to have it all done for you :)