My project is creating a website using firebase, but it is using the internal authen micro service instead of Firebase authen.
Every time the user logs in, the internal authen service will generate a token (I call it client_id), and send it to the client.
This token is also stored in the user collection.
Please help me how to write rule for the user via this client_id.
If it is write role, I can send the client_id via mothod update, delete, create and get it out by
request.resource.data.cliend_id and check it.
But if it is read role, I don't have any way to send to the client_id via the get method to authenticate users
I even thought of replacing all the get methods with the update methods to pass the client_id
But the response of the update method is just the update_time, not the object I updated
Firebase RTDB & Firestore Rules uses their own auth only. In every request that firebase client library sends uid along with jwt token and other security parameters. These are fundamental to firebase's working and thus can't be replaced.
As Aleksey mentioned, you can try custom auth. It is specifically tailored for such use cases only.
There is no way to provide extra data to security rules for the purpose of limiting read operations. That would not be secure at all, because a client could simply fake whatever they want in the query.
You can only use information provided by Firebase Auth available in request.auth, the data in the document itself in resource.data, or the contents of other documents using get(). If you want to attach additional data to the user account, consider using custom claims.
Related
I am looking to use the https.onCall to accept some input from a user (such as data about another user). I'd then like to do some advanced processing on that data including retrieving sensitive data from other entries on my firestore that should not be exposed. Depending on the outcome of that analysis, I will update other locations in the database. However, I am concerned about the security of the original call and its source. I know that I have the context parameter on the onCall to verify the source was logged in, but I'd like to apply security rules to the final write based on the context.auth provided to the cloud function.
The security rules are straight forward for normal database operations but not if I'm doing an operation (seeded by a normal user) routed through the Admin SDK.
Thoughts?
but I'd like to apply security rules to the final write based on the context.auth provided to the cloud function
As you are aware that you can identify which user made a call to functions as well as that Admin SDK has super-access to database, the general flow should be to write functions in a way that they only edit documents that should be editable by the user.
If you had still like to narrow down access, you can do that for firebase database by passing databaseAuthVariableOverride when initializing admin app.
Read more on authenticating with limited privileges
When you use the admin SDK, or any of the server SDKs, it always bypasses all security rules. Rules only apply to access coming directly from web and mobile clients using the client SDKs.
If you need to apply some sort or restricts to data written from your backend, you will need to code that into the logic of your backend code. Security rules will be of no help.
I've been following a tutorial to build a full stack website using firebase, react and redux. Log in sends a call to a back end function which uses
firebase.auth().signInWithEmailAndPassword for logging in. The IdToken is passed back to the client and stored in localstorage. Authentication and state persistence then relies on the client checking if the current date is past the expiry of the JWT token. API calls to the back end cloud functions also require an Authorization header using 'Bearer {IdToken}'.
This structure is causing me lots of headaches. I've done lots of reading and my current understanding is that firebase has it's own authorization persistence (?) that I can implement directly on my front end. Then using a listener I can automatically get new Id tokens on auth state change. This would solve my problem of the tokens expiring every hour. From what I've read local storage of the tokens is also a security risk.
I'm unsure as to how that affects authorization of my function calls. Should I still use the authorization header or is there a more elegant firebase way of doing that?
If you use Firebase Authentication's built-in providers, they indeed automatically persist the sign-in information information on most clients, restore it upon restart, and refresh the ID token just before it expires.
So if you use one of the standard providers, you can just get the user's ID token and then pass that to your Cloud Function.
You can even skip that step by using Callable Cloud Functions. For those, the Firebase Functions SDK passes the ID token along automatically, and the server automatically decodes and verifies it, and passes it to your code as context.auth.
my app is fetching data from a Firestore database but this data should only be accessible to users who are currently subscribed to In-App-Purchases.
What is the best way to protect this data?
My first thought was routing everything through a Firebase Function, so the user has to send their subscription ID to the function, the function checks it and returns the data, but this would require way too many function calls for just a few users.
If you are not using any server client libraries then you can create a rule on firestore to restrict the reads on the table.
firestore rules docs..
You could simply check if the requesting user has subscribed to In-App-Purchases (assuming there is a flag in the user's data to confirm the same).
I have a couple of http functions in my firebase project, because I prefer to hydrate, validate and update the data on the backend. I would like to use the automatic stackdriver logs, but I need to associate the log events with the authenticated user (the requests are authenticated). Is there any way to add some context to database updates? Or commit the changes in the name of the user (not the service account)?
Firestore triggers don't currently associate any information about the end user (not even if you're using Firebase Authentication and security rules), so you will have to write user information into each document in order to track who performed an action on it. It will not just appear in the environment or context.
If you go this route, I strongly suggest adding security rules that require the user to provide their Firebase Auth UID correctly in a document field, so you can be 100% sure it's correct.
Read this for more details: https://medium.com/firebase-developers/patterns-for-security-with-firebase-per-user-permissions-for-cloud-firestore-be67ee8edc4a
I use Firebase to store real time status updates for an app. I have my own authentication system for logging users in. I would like to share the data I store on Firebase to vendors who use our API, but I want to make sure they have only read access to our data.
From what I've read, it seems like securing data by user must be done through Firebase's own authentication system. Is there a way to do this without using their authentication system (maybe through a token system)?
You can definitely generate Firebase tokens in your application code, with custom properties that may be subsequently used in the Firebase security rules. Take a look at Generating a Secure Token in the Firebase docs.
Also see Can a Firebase Security Rule check if someone has specific access rights?, where #Frank van Puffelen offered a more comprehensive role-based approach.
I ended up using a system where a vendor calls one of my APIs (protected by my own internal authorization system) that returns a token that the user can use to authenticate with Firebase.
I use PHP and there is a token generator written by the Firebase team here. Don't forget the JWT PHP library this token generator relies on.
The token generator takes what is called a Firebase secret (you can find this in your particular Firebase instance page) passed into its class constructor and returns a random token based on this secret.