Zoeken…


Opmerkingen

Firebase Realtime Database-regels bepalen wie lees- en schrijftoegang heeft tot uw database, hoe uw gegevens zijn gestructureerd en welke indexen bestaan. Deze regels leven op de Firebase-servers en worden te allen tijde automatisch afgedwongen. Elk lees- en schrijfverzoek wordt alleen voltooid als uw regels dit toestaan. Standaard zijn uw regels zo ingesteld dat alleen geverifieerde gebruikers volledige lees- en schrijftoegang hebben tot uw database. Dit is om uw database tegen misbruik te beschermen totdat u tijd hebt om uw regels aan te passen of authenticatie in te stellen.

Firebase-databaseregels hebben een JavaScript-achtige syntaxis en zijn er in vier soorten:

voer hier de afbeeldingsbeschrijving in

machtiging

Uw gebruiker identificeren is slechts een onderdeel van de beveiliging. Als u eenmaal weet wie ze zijn, heeft u een manier nodig om hun toegang tot gegevens in uw database te beheren. Met Firebase-databaseregels kunt u de toegang voor elke gebruiker beheren. Hier is bijvoorbeeld een set beveiligingsregels waarmee iedereen het pad /foo/ , maar niemand er naar kan schrijven:

{
  "rules": {
    "foo": {
      ".read": true,
      ".write": false
    }
  }
}

.read en. .write regels cascade, dus deze regelset geeft leestoegang tot alle gegevens op path / foo / evenals tot diepere paden zoals /foo/bar/baz . Merk op dat .read en .write regels die toegang toestaan, andere regels in de database die geen toegang toestaan, overschrijven; met andere woorden, alle toepasselijke, .read en .write regels worden samen gebruikt). Dus leestoegang tot /foo/bar/baz zou in dit voorbeeld nog steeds worden verleend, zelfs als een regel op het pad /foo/bar/baz als onwaar wordt geëvalueerd.

De Firebase-databaseregels bevatten ingebouwde variabelen en functies waarmee u naar andere paden, tijdstempels op de server, verificatiegegevens en meer kunt verwijzen. Hier is een voorbeeld van een regel die schrijftoegang verleent aan geverifieerde gebruikers aan /users/<uid>/ , waar de ID van de gebruiker is die is verkregen via Firebase Authentication.

{
  "rules": {
    "users": {
      "$uid": {
        ".write": "$uid === auth.uid"
      }
    }
  }
}

Gegevensvalidatie

De Firebase Realtime Database is schematisch. Dit maakt het gemakkelijk om dingen te veranderen terwijl je ontwikkelt, maar zodra je app klaar is voor distributie, is het belangrijk dat gegevens consistent blijven. De .validate bevat een .validate regel waarmee u validatielogica kunt toepassen met dezelfde uitdrukkingen die worden gebruikt voor .read en .write regels. Het enige verschil is dat alle relevante validatieregels moeten worden geëvalueerd om waar te zijn om te kunnen schrijven (met andere woorden, alle toepasselijke .validate regels worden samen .validate om een database te kunnen schrijven).

Deze regel dwingt af dat gegevens geschreven naar /foo/ een string moeten bevatten van minder dan 100 karakters:

{
  "rules": {
    "foo": {
      ".validate": "newData.isString() && newData.val().length < 100"
    }
  }
}

Validatieregels hebben toegang tot alle dezelfde ingebouwde functies en variabelen als .read en .write regels. U kunt deze gebruiken om validatieregels te maken die op de hoogte zijn van gegevens elders in uw database, de identiteit van uw gebruiker, servertijd en nog veel meer.

Database-indexen definiëren

Met de Firebase Realtime Database kunt u gegevens bestellen en opvragen. Voor kleine gegevensgroottes ondersteunt de database ad hoc-query's, dus indexen zijn over het algemeen niet vereist tijdens de ontwikkeling. Voordat u uw app start, is het echter belangrijk om indexen op te geven voor eventuele vragen om ervoor te zorgen dat deze blijven werken naarmate uw app groeit.

Indexen worden opgegeven met behulp van de .indexOn regel. Hier is een voorbeeld van een indexdeclaratie die de hoogte- en lengtevelden voor een lijst met dinosaurussen zou indexeren:

{
  "rules": {
    "dinosaurs": {
      ".indexOn": ["height", "length"]
    }
  }
}


Modified text is an extract of the original Stack Overflow Documentation
Licentie onder CC BY-SA 3.0
Niet aangesloten bij Stack Overflow