web-dev-qa-db-fra.com

Ajout de champs supplémentaires aux comptes d'utilisateurs Meteor

J'utilise mrt add accounts-ui-bootstrap-dropdown et mrt add accounts-password pour obtenir une page de connexion simple en cours d'exécution sur mon application.

Les comptes utilisateurs me donnent un hash sympa contenant des identifiants, createdAt, des emails, etc.

Si je voulais ajouter d'autres champs dans ce hachage afin de pouvoir les utiliser plus tard, comment ferais-je? Par exemple, je souhaite ensuite saisir également leur prénom et nom:

"given_name": "John", "patronyme": "Doe"

meteoruser-accounts
34
user1584575

Les utilisateurs sont des objets spéciaux dans météore; vous ne voulez pas ajouter de champs dans l'utilisateur mais dans le profil des utilisateurs.

Du doc:

By default the server publishes username, emails, and profile.

Si vous souhaitez ajouter des propriétés comme le nom de famille lorsque vous créez le compte, vous devez utiliser dans le crochet côté serveur Account.onCreateUser: http://docs.meteor.com/#accounts_oncreateuser

Accounts.onCreateUser(function(options, user) {
    //pass the surname in the options

    user.profile['surname'] = options.surname

    return user
}

Si vous souhaitez mettre à jour un utilisateur après, vous pouvez le faire à partir du client de cette façon:

Meteor.users.update({_id:Meteor.user()._id}, { $set: {what you want to update} });

Par défaut, la base d'utilisateurs le permettra (l'utilisateur actuel peut se mettre à jour). Si vous ne faites pas confiance à vos utilisateurs et que vous souhaitez vous assurer que tout est correctement mis à jour, vous pouvez également interdire toute mise à jour du client et les effectuer via une Meteor.call() et procéder aux vérifications côté serveur. Mais ce serait triste.

Modifier:

Comme indiqué dans les commentaires, l'ajout d'options via le compte standard-ui ne sera pas possible. Vous ne pourrez mettre à jour l'utilisateur qu'après l'enregistrement. Pour ajouter des options lorsque vous vous abonnez, vous devrez créer votre propre formulaire.

Je ne vais pas vous insulter en écrivant du balisage html, mais voici ce que vous voulez avoir après l'événement submit (et après les différentes vérifications):

var options = {
    username: $('input#username')[0].value,
    emails: [{
        address: $('input#email')[0].value,
        verified: false
    }],
    password: $('input#password')[0].value,
    profile: {
        surname: $('input#surname')
    },
};
Accounts.createUser( options , function(err){
    if( err ) $('div#errors').html( err.message );
});

Vous n'avez besoin que du package de base de compte; pas le compte-ui.

Se connecter avec les réseaux sociaux c'est du gâteau:

Meteor.loginWithFacebook({
    requestPermissions: ['email', 'user_birthday', 'user_location']
}, function(error){loginCallBack(error);});

À propos de la réponse apportée par ram1:

Ce n'est pas ainsi que fonctionne Meteor. Vous ne "POSTEZ" pas un formulaire. Vous voulez que toutes vos communications client/serveur se fassent via le websocket. L'équivalent de ce dont vous parlez est de faire un "Meteor.call ('myserverfunction', myarguments, mycallback)" d'une méthode serveur à partir du client et vous passez les arguments que vous voulez que le serveur utilise.

Mais ce n'est pas ainsi que vous obtiendrez le meilleur des météores. Il y a la philosophie avec laquelle vous voulez travailler:

  1. vous avez des données dans votre mini mongo local que vous avez obtenues du serveur
  2. vous mettez à jour localement ces données dans votre base/vue
  3. météore fait sa magie pour transmettre ces mises à jour au serveur
  4. là, le serveur peut répondre: ok, les mises à jour sont enregistrées, c'est transparent pour vous. Ou répondez: non! annuler les modifications (et vous pouvez implémenter un système de notification d'erreur)

(il peut répondre non parce que vous n'avez pas l'autorisation de mettre à jour ce champ, car cette mise à jour enfreint une règle que vous avez définie ...)

Tout ce que vous faites est de définir des autorisations et des contrôles côté serveur sur les bases de données. De cette façon, lorsqu'un client honnête fait une mise à jour, il voit le résultat instantanément; bien avant qu'il ne soit poussé vers le serveur et envoyé aux autres clients. C'est compensation de latence, l'un des sept principes du météore.

Si vous modifiez une donnée via Meteor.call, vous le ferez:

  1. envoyer une mise à jour au serveur
  2. le serveur vérifie et met à jour la base
  3. le serveur envoie la mise à jour aux clients (y compris vous)
  4. vos mises à jour de base locales et votre vue update => vous voyez votre mise à jour

=> c'est ce que vous aviez dans l'application d'hier; météore vous permet de créer une application d'aujourd'hui. N'appliquez pas les anciennes recettes :)

40
fabien

La réponse acceptée a le droit, mais le WHERE est une information obsolète. (Oui, ce serait mieux comme commentaire sur la réponse, mais je ne peux pas encore le faire.)

De la documentation Meteor 1.2 :

La meilleure façon de stocker vos données personnalisées dans la collection Meteor.users consiste à ajouter un nouveau champ de niveau supérieur au nom unique sur le document utilisateur.

Et concernant l'utilisation de Meteor.user.profile pour stocker des informations personnalisées:

???? Ne pas utiliser le profil

Il existe un champ existant tentant appelé profil qui est ajouté par défaut lorsqu'un nouvel utilisateur s'inscrit. Ce champ était historiquement destiné à être utilisé comme bloc-notes pour les données spécifiques à l'utilisateur - peut-être leur avatar d'image, leur nom, leur texte d'introduction, etc. Pour cette raison, le champ de profil de chaque utilisateur est automatiquement inscriptible par cet utilisateur à partir du client. Il est également automatiquement publié sur le client pour cet utilisateur particulier.

Fondamentalement, il est probablement correct de stocker des informations de base telles que le nom, l'adresse, la date de naissance, etc. dans le champ de profil, mais ce n'est pas une bonne idée de stocker quoi que ce soit au-delà car cela sera, par défaut, accessible en écriture par le client et vulnérable aux utilisateurs malveillants .

13
soisystems

J'ai eu le même problème et j'ai réussi à le faire uniquement avec Accounts.createUser:

Accounts.createUser({
    email: email,
    password: password,
    profile: {
            givenName: 'John',
            surname: 'Doe',
            gender: 'M'
        }
}

C'est très simple et cela fonctionne. Ajoutez simplement vos variables souhaitées dans la section profil et cela devrait être prêt. J'espère que cela aide quelqu'un.

10
Kristiyan Lukanov

Le Guide Meteor officiel fournit une réponse complète avec un exemple de code:

La meilleure façon de stocker vos données personnalisées dans la collection Meteor.users consiste à ajouter un nouveau champ de niveau supérieur au nom unique sur le document utilisateur.

https://guide.meteor.com/accounts.html#custom-user-data

1
Amir Samakar

J'ai fini par utiliser https://atmospherejs.com/joshowens/accounts-entry qui offre une option extraSignUpFieldsconfig.

1
KindOfGuy

Depuis la documentation ( https://github.com/ianmartorell/meteor-accounts-ui-bootstrap-3/blob/master/README.md ):

Options d'inscription personnalisées

Vous pouvez définir des champs de saisie supplémentaires à afficher dans le formulaire d'inscription, et vous pouvez décider d'enregistrer ou non ces valeurs dans l'objet profil du document utilisateur. Spécifiez un tableau de champs à l'aide de Accounts.ui.config comme ceci:

Accounts.ui.config({
    requestPermissions: {},
    extraSignupFields: [{
        fieldName: 'first-name',
        fieldLabel: 'First name',
        inputType: 'text',
        visible: true,
        validate: function(value, errorFunction) {
          if (!value) {
            errorFunction("Please write your first name");
            return false;
          } else {
            return true;
          }
        }
    }, {
        fieldName: 'last-name',
        fieldLabel: 'Last name',
        inputType: 'text',
        visible: true,
    }, {
        fieldName: 'gender',
        showFieldLabel: false,      // If true, fieldLabel will be shown before radio group
        fieldLabel: 'Gender',
        inputType: 'radio',
        radioLayout: 'vertical',    // It can be 'inline' or 'vertical'
        data: [{                    // Array of radio options, all properties are required
            id: 1,                  // id suffix of the radio element
            label: 'Male',          // label for the radio element
            value: 'm'              // value of the radio element, this will be saved.
          }, {
            id: 2,
            label: 'Female',
            value: 'f',
            checked: 'checked'
        }],
        visible: true
    }, {
        fieldName: 'country',
        fieldLabel: 'Country',
        inputType: 'select',
        showFieldLabel: true,
        empty: 'Please select your country of residence',
        data: [{
            id: 1,
            label: 'United States',
            value: 'us'
          }, {
            id: 2,
            label: 'Spain',
            value: 'es',
        }],
        visible: true
    }, {
        fieldName: 'terms',
        fieldLabel: 'I accept the terms and conditions',
        inputType: 'checkbox',
        visible: true,
        saveToProfile: false,
        validate: function(value, errorFunction) {
            if (value) {
                return true;
            } else {
                errorFunction('You must accept the terms and conditions.');
                return false;
            }
        }
    }]
});
1
pmalbu