2014-05-07 10 views
32

Sto utilizzando mrt add accounts-ui-bootstrap-dropdown e mrt add accounts-password per ottenere una semplice pagina di accesso in esecuzione sulla mia app.Aggiunta di ulteriori campi agli account utente di Meteor

Gli utenti conti mi dà un bel hash che contiene gli ID, createdAt, e-mail, ecc

Se volessi aggiungere altri campi in questo hash in modo da poter fare uso di loro in seguito, come dovrei farlo? Ad esempio, voglio quindi di inserire anche il loro nome e il cognome:

"given_name": "John", "cognome": "Bianchi"

risposta

39

Gli utenti sono oggetti speciali in meteoriti; non si desidera aggiungere campi all'utente ma nel profilo utente.

Dal doc:

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

Se si desidera aggiungere le proprietà, come il cognome quando si crea l'account, è necessario utilizzare il gancio Account.onCreateUser lato server: http://docs.meteor.com/#accounts_oncreateuser

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

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

    return user 
} 

Se vuoi aggiornare un utente dopo, puoi farlo dal client in questo modo:

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

Per impostazione predefinita, la base utenti lo consentirà (l'utente corrente può aggiornarsi autonomamente). Se non ti fidi dei tuoi utenti e vuoi assicurarti che tutto sia correttamente aggiornato, puoi anche vietare qualsiasi aggiornamento dal client e renderli tramite un Meteor.call() e passare ai controlli sul lato server. Ma questo sarebbe triste.


Edit:

Come detto nei commenti, aggiungendo non sarà possibile opzioni tramite l'account-ui standard. Sarai in grado di aggiornare l'utente solo dopo la registrazione. Per aggiungere opzioni quando ti iscrivi, devi renderti proprietario della tua forma.

Non voglio insultare scrivendo Tag HTML, ma qui è ciò che si desidera avere dopo l'evento presentare (e dopo i vari controlli):

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); 
}); 

è necessario solo il pacchetto di conto-base ; non l'account-ui.

Accesso con le reti sociali è la torta:

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

Chi l'ram1 risposta fatta:

Questo non è il modo in cui le opere di meteore. Non "POST" un modulo. Vuoi che tutte le tue comunicazioni client/server siano fatte tramite la websocket. L'equivalente di ciò di cui stai parlando è un "Meteor.call ('myserverfunction', myarguments, mycallback)" di un metodo server dal client e tu passi gli argomenti che vuoi che il server usi.

Ma questo non è il modo in cui otterrete il meglio della meteora.V'è la filosofia che si desidera lavorare con:

  1. hai dati nel vostro mini locali Mongo avete ottenuto dal server
  2. si aggiorna localmente i dati nella vostra base/vista
  3. meteora fare la sua magia per trasmettere questi aggiornamenti al server
  4. lì il server può rispondere: ok, gli aggiornamenti salvati, questo è perfetto per voi. Oppure rispondi: nop! invertire le modifiche (e puoi implementare un sistema di notifica degli errori)

(può rispondere no perché non hai il permesso di aggiornare questo campo, perché questo aggiornamento infrange una regola che hai impostato ...)

Tutto ciò che devi fare è impostare autorizzazioni e controlli sui database lato server. In questo modo, quando un cliente onesto effettua un aggiornamento, vede immediatamente il risultato; molto prima che sia stato inviato al server e inviato agli altri client. Questo è compensazione latenza, uno dei sette principi della meteora.

Se si modifica un dati tramite Meteor.call, si farà che:

  1. inviare un aggiornamento al server
  2. i controlli server e aggiornare la base di
  3. il server invia l'aggiornamento i clienti (voi compresi)
  4. gli aggiornamenti di base locali e l'aggiornamento view => vedi il tuo aggiornamento

=> questo è ciò che hai avuto in app ieri; meteora ti permette di costruire un'app oggi. Non applicare le vecchie ricette :)

+0

Questa è una risposta eccellente. Tuttavia, l'avvertimento che vorrei fornire è che l'OP dovrebbe passare un argomento 'options' ad una chiamata' Accounts.createUser 'lato client, come si fa notare, ma questo potrebbe non essere banale se si basa su ' account-ui-bootstrap-dropdown', che probabilmente gestirà quella chiamata per lui. Non ho familiarità con il pacchetto, e comunque ci sarà un modo facile per aggirare questo (anche se si tratta di biforcazione), ma comunque penso che avrà bisogno di scavare nel pacchetto un po 'più di quello che suggerisci. – richsilv

+1

Se vuole aggiungere campi quando l'utente si sta registrando, deve creare il proprio modulo di registrazione; lo standard dal pacchetto base non lo farà facilmente. Solo perché richiederebbe l'aggiunta di campi. Modifico la mia risposta per spiegare come :) – fabien

+0

Sembra che questa spiegazione di Meteor.call sia corretta solo se il metodo chiamato è memorizzato esclusivamente nel codice del server. Inserisci i metodi nel tuo account lib in modo che siano disponibili su client e server e la compensazione della latenza dovrebbe funzionare correttamente. :) Altrimenti puoi entrare nelle regole allow/deny, anche se sembra davvero più messico che chiamare metodi Meteor isomorfi. –

9

Ho avuto lo stesso problema e sono riuscito a farlo solo con Accounts.createUser:

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

Quello è modo molto semplice e funziona. Basta aggiungere le variabili desiderate nella sezione profilo e dovrebbe essere pronto. Spero che aiuti qualcuno.

+1

Questo semplicemente funziona. Immagino che il profilo sia il file che può essere personalizzato di default. –

11

La risposta accettata ha il diritto HOW, ma il WHERE è informazioni obsolete. (Sì, questo sarebbe meglio come un commento alla risposta, ma non posso farlo ancora.)

Dal Meteor 1.2 documentation:

Il modo migliore per memorizzare i dati personalizzati sul Meteor. la raccolta di utenti consiste nell'aggiungere un nuovo campo di primo livello con un nome univoco sul documento dell'utente.

E sull'utilizzo di Meteor.user.profilo per archiviare informazioni personalizzate:

Non utilizzare il profilo

C'è una tentazione campo esistente denominato profilo che viene aggiunto da impostazione predefinita quando un nuovo utente si registra. Questo campo è stato storicamente destinato ad essere utilizzato come appunti per i dati specifici dell'utente - forse loro immagine avatar, nome, testo introduttivo, ecc A causa di questo, il campo profilo su ogni utente viene automaticamente scrivibile da quell'utente dal cliente. Viene anche automaticamente pubblicato sul client per per quel particolare utente.

Fondamentalmente, è probabilmente bene per memorizzare le informazioni di base come nome, indirizzo, data di nascita, ecc nel campo del profilo, ma non è una buona idea per memorizzare nulla al di là che come sarà, per impostazione predefinita, essere scrivibile dal client e vulnerabili agli utenti malintenzionati.

1

Dalla documentazione (https://github.com/ianmartorell/meteor-accounts-ui-bootstrap-3/blob/master/README.md):

opzioni di iscrizione personalizzati

È possibile definire campi di input aggiuntivi per apparire nel modulo di iscrizione, e si può decidere wether per salvare questi valori per l'oggetto profilo del documento utente o no. Specificare un array di campi utilizzando Accounts.ui.config in questo modo:

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

la guida ufficiale Meteor fornisce una risposta completa con un codice di esempio:

Il modo migliore per memorizzare i dati personalizzati sul La collezione Meteor.users consiste nell'aggiungere un nuovo campo di livello superiore con un nome univoco sul documento dell'utente.

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