meteor
Meteor-användarkonton

Meteorkontopaket

Du har några alternativ när det gäller att logga in med Meteor. Den vanligaste metoden är att använda accounts för Meteor.

Accounts-lösenord

Om du vill att användare ska kunna skapa och registrera sig på din webbplats kan du använda accounts-password .

Installera paketet med hjälp av meteor add accounts-password .

För att skapa en användare måste du använda Accounts.createUser(options, [callback])

options måste vara ett objekt med följande egenskaper:

• username : Användarens användarnamn som en sträng ..
• email : användarens e-post som en sträng.
• password : Användarens (inte krypterade) lösenord som en sträng.
• profile : Användarens extra data som tillval. Detta kan till exempel vara användarens för- och efternamn. profile är dock valfri.

Återuppringningen returnerar 1 variabel om det finns ett fel, som är ett Meteor.Error-objekt.

Du måste bara använda antingen username eller email , så du kan skapa en användare med användarnamn men ingen e-post, och vice versa. Du kan också använda båda.

Det returnerar det nyligen skapade användar-ID om allt gick korrekt.

Så du kan till exempel använda detta:

// server side
var id = Accounts.createUser({
    username: "JohnDoe",
    email: "[email protected]",
    password: "TheRealJohn123",
    profile: {
        firstName: "John",
        lastName: "Doe"
    }
}, function(err) {
    console.log(err.reason);
});

Det kommer automatiskt att logga in dig också om användaren har skapats.

Det är den skapande delen. För att logga in måste du använda Meteor.loginWithPassword(identifier, password, [callback]) på klientsidan.

identifier är username , email eller userId som en sträng från din användare. password är (inte krypterat) password för användaren.

Återuppringningen returnerar en variabel om det finns ett fel, som är ett Meteor.Error-objekt.

Exempel:

// client side
Meteor.loginWithPassword("JohnDoe", "TheRealJohn123", function(err) {
    console.log(err.reason);
});

Och det är det för grundläggande skapande av konton och inloggning.

Få åtkomst till användardata

Du kan kontrollera på klientsidan om användaren är inloggad genom att ringa Meteor.userId() vilket kommer att returnera sin userId om de är inloggade och undefined om de inte är inloggade.

Du kan få en del av informationen från Meteor.user() . Det returneras odefinierat om användaren inte är inloggad och vissa användardata om de är det. Det kommer inte att ge dig några lösenord som standard, som standard kommer det att visa användarens användarnamn, användarnamn och profilobjekt.

Om du vill kontrollera om en användare är inloggad på en sida kan du också använda den currentUser . Det returnerar innehållet i Meteor.user() . Exempel:

{{#if currentUser}}
    <h1>Hello there, {{currentUser.username}}!</h1>
{{else}}
    <h1>Please log in.</h1>
{{/if}}

Andra konton funktioner

Det finns några andra funktioner som fungerar för varje kontopaket.

Du kan logga ut med Meteor.logout()

Använd inte standardprofilfältet

Det finns ett frestande befintligt fält som heter profile som läggs till som standard när en ny användare registrerar sig. Detta fält var historiskt avsett att användas som en skrapplatta för användarspecifik data - kanske deras bildavatar, namn, introtext, etc. På grund av detta kan profile för varje användare automatiskt skrivas av den användaren från klienten . Det publiceras också automatiskt till klienten för den specifika användaren.

Det visar sig att det inte är den bästa idén att ha ett fält skrivbart som standard utan att göra det så uppenbart. Det finns många berättelser om nya Meteor-utvecklare som lagrar fält som isAdmin profile ... och sedan kan en skadlig användare enkelt ställa in det till sant när de vill, vilket gör sig till en administratör. Även om du inte är orolig för detta är det inte bra att låta skadliga användare lagra godtyckliga mängder data i din databas.

I stället för att ta itu med det som finns inom detta område kan det vara till hjälp att helt enkelt ignorera dess existens. Du kan säkert göra det så länge du förnekar alla skriv från klienten:

// Deny all client-side updates to user documents
Meteor.users.deny({
  update() { return true; }
});

Även om man ignorerar profilens säkerhetsimplikationer är det inte bra att lägga all din apps anpassade data på ett fält. Meteors dataöverföringsprotokoll gör inte djupa kapslade skillnader i fält, så det är en bra idé att platta ut dina objekt i många toppnivåfält i dokumentet.