I am working on a major update to my app and I wanted to take advantage of Firestore's offline persistence (web) as a caching layer (as described in this recent Firebase video: https://youtu.be/iQOTjUko9WM ).
I have a tester who swears she has no security-related extensions installed. Or even any sort of third-party app meant to 'harden' a device.
But my app's offline persistence does not work for her... and only her, out of about 20 testers.
In Chrome she sees a message "Audit usage of navigator.useragent navigator.appversion and navigator.platform" in her console (but hasn't toggled the triangle to see if there is more info).
In Edge she sees "tracking prevention blocked access to storage for..." and that is followed by "FirebaseError: Failed to get document from cache..."
Is there some sort of permission request needed in some cases? Or some sort of 'defensive' check I need to add before using getDocFromCache()?
I really want to use offline persistence as a cache to prevent unnecessary reads as the user moves around in my app. Thanks in advance!
Sounds like they've got strict tracking prevention mode enabled in Edge (and the equivalent in Chrome).
Have them check (for Edge) Privacy, search, and services -> Tracking Prevention. If it is set to Strict move back to Balanced, also check for Blocked trackers and/or allow an Exception.
Related
We are building an app for our teams out in the field that they collect their daily information using Firebase. However one of our concerns is poor connectivity. We are looking to build an Online/Offline button they can click to essentially work offline for when things slow down. We've built a workflow in which we query all the relevant information from Firestore.
I wanted to know if there was a way to tell Firestore to work directly on the cache only and not try to hit the servers directly. I don't want Firestore attempting to make server calls until they enable online again.
You shouldn't need to do this. If you use realtime listeners, they will already first return the data from the local cache, and only then reach out to the server to check for updates.
If you are performing one-time reads, the SDK will by default try to reach the server first (since it has only one chance to give you a value). If you want it to only check the local cache, you can pass an argument to the get call to do so.
You can also disable the network completely, in which case the client will never call on the network and only serve from the local cache. I recommend reading about that and more in the documentation on using Firestore offline.
I'm currently running a project that uses Firebase Hosting and Firebase Functions. Both functions apparently use some cookies for their own reasons, but I can't seem to find a way to 'disable' them for my website visitors.
All around, I'm not very well informed on GDPR laws, but I'd like my webpage to comply with those, by giving users the chance to opt out of cookies.
Is there a way to disable those cookies? And if not, is it possible that they are already GDPR compliant?
Cheers.
The cookies used for Firebase are specifically for Authentication reasons only, Firebase doesn't track personal information or data but rather stores a randomized Javascript Web Token to re-authenticate a user when your app gets refreshed or reloaded.
Additional client-side data is used for caching the database to increase read performance but doesn't expose or track a user by any means either.
My assumption was that Firestore would not consider the client cache when evaluating Read usage. However, when I have persistence enabled in my application, it seems I can run the same queries endlessly and not see any change in my usage metrics. I've tested this over and over - when persistence is disabled, I see the usage metrics go up.
Given the amount of testing I've done, I feel that I should be able to safely declare that Firestore must be recognizing my local cache and only charging me for Reads on updated documents. However, I cannot find documentation around this anywhere, and I have combed through the docs. I'd certainly think if Google wasn't charging me for these cached Reads that they would want to highlight that benefit, whereas they really only highlight enablePersistence as an offline benefit - so I am perplexed.
Does someone have some insight into what is going on here?
Example enable persistence: firebase.firestore().enablePersistence()
Example query: myCollection.where(condition).get()
According to this documentation
Offline data persistence feature caches a copy of the Cloud Firestore data that your app is actively using, so your app can access the data when the device is offline
So, it is clear that you will only be charged when calling get() on the server to-read documents, mentioned in this answer
Also, be aware that
Offline Persistance is enabled by default for Android and iOS.
The pricing model for Cloud Firestore
This is a really great question. To clarify what the question is asking: "If my app is online and makes a query, but the query is fully returned by the offline cache, will I still be charged?"
I suspect yes.
Is it possible to either turn off the api explorer completely or limit the access to it?
I noticed some logs in my app that come from failed requests executed from a browser. My api is only consumed by an Android app so the only place where they can come from is the api explorer. Also the api access is limited to 1 web and 1 android client id.
Unfortunately no. The API explorer works by using the Discovery Service associated with your API, which is not actually part of your backend, so you can't specify auth or visibility for those URIs.
The list method from the Discovery service is used to generate the list on the APIs Explorer app using your app as base:
discovery.apis.list:
your-app-id.appspot.com/_ah/api/discovery/v1/apis
When someone clicks one of the APIs from the list, the full discovery document is retrieved for that apiName and apiVersion using the getRest method from the Discovery service:
discovery.apis.getRest:
your-app-id.appspot.com/_ah/api/discovery/v1/apis/{apiName}/{apiVersion}/rest
If you are looking for ways to prevent the executing of the API, check out Cloud Endpoints: Control who can execute API through API Explorer
endpoints makes auth easy and you can get the current user. You should use auth to ensure people don't mess with your private apis - otherwise people could trace what kind of post or get requests you're sending anyway - auth is always a good idea rather than trying to keep your apis secret.
If you're building a secret product and you don't want your competitor to find out, you could perhaps use some obfuscation method on the backend and on your client which makes the apis unreadable.
Also a user messing with your apis shouldn't break your database - or if it does - it should only break it for the user that was being foolish. Having logic in your client for how apis are used so that the backend doesn't break is a bad idea - the backend apis should take care of themselves and not worry about how or why they are used and who by for what purpose.
I read this at the docs:
Database Everywhere. Use the same transparent API to access your
database from the client or the server.
This is great, but I think there are some security issues. Providing full and transparent access to the database at client side you are exposed to bad users, which modify you JS code (it's really at his browser and he can do it) and add any database action that could retrieve/remove/update data that perhaps could be sensible.
Please, correct me if I'm wrong.
Thanks!
You are correct. The developers are currently working on Auth and security concerns. As of now everything is open and great for creating prototypes and test apps however they are vulnerable to users retrieve/remove/update data as they like.
See the developer response to this question here: Link
Meteor now includes restrictions on client database writes (allow and deny) and a complete user accounts system.
Secure your app by removing the insecure and autopublish packages:
meteor remove insecure autopublish