And I’ll use the word “indirect” for access going through Cloud Functions, or some other backend you control. In this article, I’ll use the word “direct” to talk about database access using the Firebase SDKs that query a database without going through a backend. But how do you make that decision? When is it better to directly query from the client, and when is it better to route the request through a backend? There’s no right or wrong answer here, so let’s weigh each option by the properties that matter the most. But there are some situations when you want to route all requests through a server side component, such as Cloud Functions, to manage the query. Firebase makes this easy by providing SDKs for apps to directly read and write the databases provided by the platform ( Realtime Database and Cloud Firestore). This is useful since even when the APIkey of your app/site is available for third-parties, the requests wont do any operations to your data without an authenticated-and-roled user.Just about every app you use has to query a database and show the results on screen. In the same collection of settings, when a request for writing comes, the upsert is available only for authenticated users with a role of admin.There is a collection of settings, when a request for reading comes, the fetching is available only for authenticated users with a role of admin or regular.The function isRegular(),just like isAdmin() looks for a particular token, in this case, the regular token, if presented, the request is validated.
The function isAdmin(), when is invoked by an authenticated user, it looks for a particular token, in this case, the admin token, if presented, the request is validated.The functions created always ask whether the request incoming is related to a user authenticated, otherwise, the access is invalid and the request is denied.The default schema for production mode looks like this:Įnter fullscreen mode Exit fullscreen mode Under this mode, any access is explicitly denied, this forces the developer to add some logic for explicitly allowing users to access the resources. Whenever you start a new Firebase project, in the section Firestore/Rules, creating a new db project will present 2 options, you can opt any of those in, let's see the difference: Allow/Deny access according to auth states and functions.Writing rules straight in console vs versioned file.Rule(dammit once again!).Īnyway, when you work with Firebase you see the features related to store some kind of information have their own Rules tab, this is the way you can declare for allowing/denying the access to certain resources based on the user who is trying the request.Ī bad practice is to keep the resources open for everybody throughout the web, if so, anyone could perform CRUD operations on your site/app, modify assets, or even remove collections(and I am pretty sure you don't want that, do you?), you can read more information right here.ĭisclaimer: For this post, a shallow explanation will be given related to Firestore ans Security Rules version 2, released on May 2019 Rules, rules and rules, we always hear about rules to follow for interacting with databases, endpoints, programming languages, and well, Firebase Firestore is not the exception to the. Hello developer pal!, glad to see you here.
0 kommentar(er)
