Firebase-beveiligingsregels

Firebase Realtime Databaseveiligheidsregels zijn hoe u uw gegevens beveiligt tegen ongeautoriseerde gebruikers en uw gegevensstructuur beschermt.  

In deze quicktip-zelfstudie zal ik uitleggen hoe u de databaseveiligheidsregels juist kunt configureren, zodat alleen bevoegde gebruikers lees- of schrijftoegang tot gegevens hebben. Ik zal u ook laten zien hoe u uw gegevens kunt structureren zodat deze eenvoudig te beveiligen zijn.

Het probleem

Laten we aannemen dat we JSON-gegevens in onze Firebase-database hebben, zoals in het onderstaande voorbeeld:

"users": "user1": "firstName": "Chike", "lastName": "Mgbemena", "age": "89" "phoneNumber": "07012345678", "user2": "firstName ":" Godswill "," lastName ":" Okwara "," age ":" 12 "" phoneNumber ":" 0701234 "," user3 ": " firstName ":" Onu "," lastName ": 543," age ": 90" phoneNumber ":" 07012345678 ", ...

Als u naar de database kijkt, ziet u dat er enkele problemen zijn met onze gegevens:

  1. Twee gebruikers (user1 en user3) hebben dezelfde telefoonnummers. We willen dat deze uniek zijn.
  2. user3 heeft een nummer voor de achternaam, in plaats van een string.
  3. user2 heeft slechts zeven cijfers in hun telefoonnummer, in plaats van 11. 
  4. De leeftijdswaarde voor user1 en user2 is een string, terwijl die van user3 is een nummer.

Met al deze tekortkomingen in onze gegevens benadrukt, hebben we de gegevensintegriteit verloren. In de volgende stappen zal ik u laten zien hoe u kunt voorkomen dat deze zich voordoen. 

Toegeeflijke regels

De realtime-database van Firebase heeft de volgende soorten regels:

Type Functie
.lezen Beschrijft of en wanneer gegevens mogen worden gelezen door gebruikers.
.schrijven Beschrijf of en wanneer gegevens mogen worden geschreven.
.bevestigen Bepaalt hoe een correct opgemaakte waarde eruit zal zien, of deze onderliggende kenmerken heeft en het gegevenstype.
.indexOn Specificeert een onderliggende index om het ordenen en bevragen te ondersteunen.

Lees meer over hen in de Firebase-documenten.

Hier is een zeer permissieve regel voor de gebruikers sleutel in onze database. 

"rules": "users": // gebruikers kunnen door iedereen worden gelezen ".read": true, // gebruikers kunnen door iedereen worden beschreven ".write": true

Dit is slecht, omdat het iedereen de mogelijkheid biedt om gegevens in de database te lezen of te schrijven. Iedereen kan toegang krijgen tot het pad / Users / evenals diepere paden. Niet alleen dat, maar er wordt geen structuur opgelegd aan de gegevens van de gebruikers.

Toegangsregels

"rules": "users": "$ uid": ".read": "auth.uid == $ uid", ".write": "auth.uid == $ uid", 

Met deze regels bepalen we de toegang tot de gebruikersrecords voor ingelogde gebruikers. Niet alleen dat, maar gebruikers kunnen alleen hun eigen gegevens lezen of schrijven. We doen dit met een wildcard: $ uid. Dit is een variabele die de onderliggende sleutel vertegenwoordigt (namen van variabelen beginnen met $). Bijvoorbeeld toegang tot het pad / Users / user1, $ uid is "User1"

Vervolgens maken we gebruik van de auth variabele, die de momenteel geverifieerde gebruiker vertegenwoordigt. Dit is een vooraf gedefinieerde servervariabele die wordt geleverd door Firebase. In regel 5 en 6 dwingen we een toegankelijkheidsbeperking af dat alleen de geverifieerde gebruiker met dezelfde id als de gebruikersrecord de gegevens kan lezen of schrijven. Met andere woorden, voor elke gebruiker wordt lees- en schrijftoegang verleend aan / Users //, waar staat voor het huidig ​​geverifieerde gebruikers-ID.

Andere Firebase-servervariabelen zijn:  

nu De huidige tijd in milliseconden sinds het tijdperk van Linux.
wortel EEN RuleDataSnapshot die het root-pad in de Firebase-database representeert zoals deze bestond vóór de geprobeerde bewerking. 
nieuwe data EEN RuleDataSnapshot de gegevens representeren zoals die zouden bestaan ​​na de poging tot operatie. Het bevat de nieuwe gegevens die worden geschreven en bestaande gegevens. 
gegevens Een RuleDataSnapshot die de gegevens weergeeft zoals deze vóór de geprobeerde bewerking bestonden.
auth Vertegenwoordigt de nuttige lading van een geverifieerde gebruiker.

Lees meer over deze en andere servervariabelen in de Firebase-documenten.

Gegevensstructuur afdwingen

We kunnen ook Firebase-regels gebruiken om beperkingen op de gegevens in onze database af te dwingen. 

In de volgregels in de regels 8 en 11 zorgen we bijvoorbeeld ervoor dat regels een nieuwe waarde voor de voor- en achternaam een ​​tekenreeks moeten zijn. In regel 14 zorgen we ervoor dat leeftijd een getal is. Tot slot, in regel 17 en 18, zorgen we ervoor dat de waarde van het telefoonnummer een tekenreeks is met een lengte van 11.

"rules": "users": "$ uid": ".read": "auth.uid == $ uid", ".write": "auth.uid == $ uid", "firstName" : ".validate": "newData.isString ()", "lastName": ".validate": "newData.isString ()", "age": ".validate": "newData.isNumber ( ) "," phoneNumber ": " .validate ":" newData.isString () && newData.val (). length == 11 ",

Maar hoe voorkomen we dubbele telefoonnummers?

Duplicaten voorkomen

Vervolgens laat ik zien hoe je dubbele telefoonnummers kunt voorkomen.

Stap 1: de gegevensstructuur normaliseren

Het eerste dat we moeten doen, is het hoofdpad wijzigen om een ​​topniveau op te nemen /telefoonnummers/ knooppunt. Dus, wanneer een nieuwe gebruiker wordt gemaakt, voegen we ook het telefoonnummer van de gebruiker toe aan dit knooppunt wanneer de validatie succesvol is. Onze nieuwe gegevensstructuur ziet er als volgt uit:

"users": "user1": "firstName": "Chike", "lastName": "Mgbemena", "age": 89, "phoneNumber": "07012345678", "user2": "firstName" : "Godswill", "lastName": "Okwara", "age": 12, "phoneNumber": "06034345453", "user3": "firstName": "Onu", "lastName": "Emeka", " age ": 90," phoneNumber ":" 09034564543 ", ...," phoneNumbers ": " 07012345678 ":" user1 "," 06034345453 ":" user2 "," 09034564543 ":" user3 ", ... 

Stap 2: Nieuwe gegevensstructuur afdwingen

We moeten de beveiligingsregels aanpassen om de gegevensstructuur af te dwingen: 

"rules": "users": "$ uid": ... "phoneNumber": ".validate": "newData.isString () && newData.val (). length == 11 &&! root.child ('phoneNumbers'). child (newData.val ()). exists () ",

Hier zorgen we ervoor dat het telefoonnummer uniek is door te controleren of het al een kind is van de /telefoonnummers/ knoop met het gegeven telefoonnummer als sleutel. Met andere woorden, we controleren of het telefoonnummer al door een gebruiker is geregistreerd. Als dit niet het geval is, is de validatie geslaagd en wordt de schrijfbewerking geaccepteerd, anders wordt deze geweigerd. 

Uw app moet het telefoonnummer toevoegen aan de lijst met telefoonnummers bij het maken van een nieuwe gebruiker en moet het telefoonnummer van een gebruiker verwijderen als die gebruiker wordt verwijderd.

Validatie en beveiligingsregels simuleren

U kunt uw beveiligingsregels in de Firebase-console simuleren door op te klikken Simulator knop. Voeg uw beveiligingsregels toe, selecteer het type simulatie (lezen of schrijven), voer wat gegevens in met een pad en klik op Rennen knop: 

Als de waarde van de voornaam een ​​getal is in plaats van een tekenreeks, mislukt de validatie en wordt de schrijftoegang geweigerd:

Conclusie

In deze quicktip-zelfstudie hebt u geleerd over Firebase Database-beveiligingsregels: hoe u ongeoorloofde toegang tot gegevens kunt voorkomen en hoe u ervoor kunt zorgen dat de gegevens in de database gestructureerd zijn.

Raadpleeg de officiële documentatie voor meer informatie over Firebase Database-beveiligingsregels. Bekijk ook enkele van onze andere Firebase-zelfstudies en cursussen hier op Envato Tuts+!