2014-05-07 13 views
32

Używam mrt add accounts-ui-bootstrap-dropdown i mrt add accounts-password, aby uzyskać prostą stronę logowania uruchomioną w mojej aplikacji.Dodawanie kolejnych pól do kont użytkowników Meteor

Użytkownikom rachunków daje mi piękny hash zawierający identyfikatory, createdAt, e-maile itp

Gdybym chciał dodać inne pola w tej hash więc mogę skorzystać z nich później, w jaki sposób to zrobić? Na przykład, chcę potem także wprowadzić swoje imię i nazwisko:

„GIVEN_NAME”: „John”, „nazwisko”: „Kowalski”

Odpowiedz

39

Użytkownicy są specjalne przedmioty w meteor; nie chcesz dodawać pól do użytkownika, ale do profilu użytkownika.

Z Doc:

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

Jeśli chcesz dodać właściwości jak nazwiskiem podczas tworzenia konta, należy użyć w haku Account.onCreateUser server-side: http://docs.meteor.com/#accounts_oncreateuser

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

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

    return user 
} 

Jeśli chcesz zaktualizować użytkownika po, możesz zrobić to od klienta w ten sposób:

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

Domyślnie baza użytkowników zezwala na to (bieżący użytkownik może się aktualizować). Jeśli nie ufasz swoim użytkownikom i chcesz się upewnić, że wszystko jest poprawnie zaktualizowane, możesz również zabezpieczyć wszelkie aktualizacje od klienta i wykonać je poprzez Meteor.call() i przejść do strony serwera sprawdzającego. Ale byłoby to smutne.


Edit:

Jak powiedział w komentarzach, dodając opcje za pośrednictwem standardowego interfejsu konta nie będzie możliwe. Będziesz mógł aktualizować użytkownika dopiero po rejestracji. Aby dodać opcje podczas subskrypcji, musisz utworzyć własny formularz.

nie będę obrażać pisząc znaczników HTML, ale tutaj jest to, co chcesz mieć po zdarzeniu przedstawienia (i po różnych kontroli):

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

Trzeba tylko pakiet podstawowy konta ; nie konto-ui.

Zaloguj się z sieci społecznych jest ciasto:

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

O ram1 odpowiedzi wykonany:

To nie jest droga prace meteorów. Nie "POST" formularza. Chcesz, aby cała twoja komunikacja klient/serwer odbywała się za pośrednictwem websocket. Odpowiednikiem tego, o czym mówisz, jest "Meteor.call (" funkcja myserverfunction ", myarguments, mycallback)" metody serwera od klienta i przekazujesz argumenty, których serwer ma użyć.

Ale to nie jest sposób, w jaki zdobędziesz najlepsze meteory.Jest to filozofia chcesz pracować z:

  1. masz dane teleadresowe w lokalnych mini Mongo masz z serwera
  2. zaktualizować lokalnie te dane teleadresowe twojej bazy/view
  3. meteor wykonywać swoją magię przesłać te aktualizacje na serwer
  4. tam serwer może odpowiedzieć: ok, aktualizacje zapisane, to jest płynne dla ciebie. Lub odpowiedz: nop! odwróć zmiany (i możesz zaimplementować system powiadamiania o błędach)

(może odpowiedzieć "nie", ponieważ nie masz uprawnień do aktualizacji tego pola, ponieważ ta aktualizacja powoduje złamanie reguły, którą skonfigurowałeś ...)

Wszystko, co robisz, to ustawianie uprawnień i kontroli na serwerze po stronie baz danych. W ten sposób, gdy uczciwy klient robi aktualizację, natychmiast widzi rezultat; zanim zostanie przekazany na serwer i wysłany do innych klientów. Jest to kompensacja opóźnienia, jedna z siedmiu zasad meteorytu.

Jeśli modyfikowanie danych za pośrednictwem Meteor.call, można to zrobić:

  1. wysłać aktualizacji do serwera
  2. serwer sprawdza i aktualizuje bazę
  3. serwer wysłać aktualizację klienci (w tym siebie)
  4. lokalnych aktualizacjach bazowych i aktualizacją view => widzisz swoją aktualizacja

=> to co miałeś wczoraj aplikację; meteor pozwala zbudować dzisiejszą aplikację. Nie stosuj starych receptur :)

+0

Jest to doskonała odpowiedź. Jednakże zastrzeżenie, które chciałbym podać, to fakt, że OP będzie musiał przekazać argument "options" do po stronie klienta "Calls.createUser", jak zauważysz, ale to może nie być całkowicie banalne, jeśli opiera się na '. pakiet accounts-ui-bootstrap-dropdown', który prawdopodobnie będzie obsługiwał to żądanie dla niego. Nie jestem zaznajomiony z paczką, a zresztą nie będzie to łatwe (nawet jeśli wymaga to rozwidlenia), ale mimo wszystko myślę, że będzie musiał zagłębić się w paczkę nieco więcej niż sugerujesz. – richsilv

+1

Jeśli chce dodać pola podczas rejestracji, musi utworzyć własny formularz rejestracyjny; standardowe wyjście z pakietu podstawowego nie będzie tak łatwe. Tylko dlatego, że wymagałoby dodania pól. Edytuję odpowiedź, aby wyjaśnić, w jaki sposób :) – fabien

+0

Wygląda na to, że to wyjaśnienie Meteor.call jest poprawne tylko wtedy, gdy wywołana metoda jest przechowywana wyłącznie w kodzie serwera. Umieść metody na swoim koncie lib, aby były dostępne zarówno na kliencie, jak i na serwerze, a kompensacja opóźnienia powinna działać poprawnie. :) W przeciwnym razie można uzyskać reguły zezwalające/odmawiać, choć wydaje się to bardziej bałamutne niż wywoływanie metod izomorficznych Meteor. –

9

miałem ten sam problem i udało mu się to zrobić tylko z Accounts.createUser:

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

Thats bardzo prosty sposób i to działa. Wystarczy dodać pożądane zmienne w sekcji profilu i powinno być gotowe. Mam nadzieję, że to komuś pomaga.

+1

To po prostu działa. Domyślam się, że profil to plik, który można domyślnie dostosować. –

11
Przyjęta odpowiedź ma JAK, ale GDZIE jest nieaktualna. (Tak, to byłoby lepiej jako komentarz na odpowiedź, ale nie mogę tego zrobić jeszcze.)

Z Meteor 1.2 documentation:

Najlepszym sposobem przechowywania danych niestandardowych na Meteor. kolekcja użytkowników polega na dodaniu nowego unikatowego pola najwyższego poziomu w dokumencie użytkownika.

W odniesieniu do używania Meteor.user.profil do przechowywania niestandardowe informacje:

Nie używaj profilowi ​​

Jest kuszące istniejącego pola o nazwie profilu, który jest dodawany przez domyślnie kiedy nowy rejestrów użytkowników. To pole było historycznie przeznaczone do użycia jako podkładka podrapania dla danych specyficznych dla użytkownika - być może ich awatar, nazwa, tekst wprowadzający, itp. Z tego powodu pole profilu dla każdego użytkownika jest automatycznie zapisywane przez tego użytkownika od klienta. Jest również automatycznie publikowany dla klienta dla tego konkretnego użytkownika.

Zasadniczo dobrze jest przechowywać podstawowe informacje, takie jak imię, nazwisko, adres, imię i nazwisko itp. W polu profilu, ale nie jest dobrym pomysłem przechowywanie czegokolwiek poza nim, ponieważ domyślnie będzie możliwe zapisywanie przez klienta i jest podatny na złośliwych użytkowników.

1

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

opcje klienta Rejestracja

Można zdefiniować dodatkowe pola wejściowe do stawienia się w formularzu rejestracji, można zdecydować pogoda zapisać te wartości do obiektu profilu dokumentu użytkownika lub nie. Określić szereg dziedzin wykorzystujących Accounts.ui.config tak:

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

Oficjalna Meteor przewodnik zapewnia kompleksową odpowiedź z kodem Przykład:

Najlepszym sposobem przechowywania danych na niestandardowe Kolekcja Meteor.users polega na dodaniu nowego jednoznacznie nazwanego pola najwyższego poziomu w dokumencie użytkownika.

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

Powiązane problemy