We all know that securing your database from malicious or misguided clients is critical. And with Security Rules for Cloud Firestore, you can create a very powerful access control system with simple matching syntax and logic.
Until now, however, testing your rules was difficult. You couldn't test your rules before deploying them, and running arbitrary tests against these rules (to ensure they worked the way you expected) wasn't easy, either.
Today, we're pleased to announce our first big step in making it easier to secure your Cloud Firestore database with the release of the Rules Simulator.
With the new Rules Simulator in the Firebase console, you can test your rules as you write them — and before you deploy!
The simulator lets you test document reads, writes, and deletes against any part of your Cloud Firestore database. It will also let you simulate being signed in with a particular userID, so you can better test user-based access control. And for more sophisticated auth-based security, the simulator will help you build authentication tokens for various providers, giving you a preview of what that token will look like and allowing you to directly map the shape of the token to the rules you are writing.
The simulator tests against the rules as they are currently drafted in your editor, not as they are in deployment, allowing you to rapidly test different rules with different types of requests. This means that next time you click the publish button, you can have more confidence that your rules are protecting your data and doing exactly what you expect them to do!
You can get started today with the simulator by navigating over to the Rules section of the Firestore panel in the console.
We've also significantly increased the number of get(), exists() and getAfter() calls you can make in each security rule. For a single document request, you can now make 10 document access calls (up from 3). For multi-resource requests, such as batched writes, you'll be able to make a total of 20 document access calls for all documents in that request.
get()
exists()
getAfter()
Check out our documentation for more information and examples.
Firestore Security Rules may look like JavaScript, but they're actually a purpose-built language with its own unique syntax and behavior. While we've always provided guides to help you write security rules, many developers mentioned to us that it is too hard to discover all of the functions, types, and edge-cases that you need to learn in order to write complex rules.
That's why we published comprehensive reference documentation on the security rules language and the built-in types and functions that it provides. We hope this will enable you to be more confident when writing advanced rules conditions.
The Cloud Firestore data viewer in the console is a great place to view and update data. You can watch in real time as documents and fields update.
We all know that Cloud Firestore scales to huge amounts of data automatically -- but what about the data viewer? Until now, it was hard to navigate through a big dataset.
To solve the problem, we added a new feature that lets you order and filter right in the data viewer.
We think this will be especially useful in two scenarios:
Sorting by a field. Let's say you have a field last_updated on all of your documents in a collection users, and you want to see the documents that were updated most recently. Just open the menu, choose the field last_updated, select Descending and click apply.
last_updated
users
Descending
Finding a specific document. Perhaps you have a collection of users which has the fields email and last_updated, and someone tells you they are having a problem with their account. Using the filter menu, input the field email and add a condition (email == "test@gmail.com") to instantly find that user's document.
email
email == "test@gmail.com"
These are just a few ways that you can use the new menu. We hope it helps you browse large datasets with ease.
Firebase Dynamic Links are deep links that drive user growth and engagement by allowing you to send users to specific places in your app - across iOS, Android, and the web. Dynamic Links retain their context and attribution data, even if a user needs to install your app first, ensuring new users see the content they're looking for right away. While Dynamic Links can be useful in a number of situations, we heard from many of you that you wanted more ways to customize the actual URL that made up a Dynamic Link.
In the past, Dynamic Links contained a randomly generated subdomain that could not be customized. So when you created a new link, it would look something like https://a7cd8.app.goo.gl/B7vVu.
https://a7cd8.app.goo.gl/B7vVu
Today, we're excited to introduce three ways you can customize your dynamic links: a brand agnostic domain, custom subdomains, and custom paths. Moving forward, you can update your links from something that looks like https://a7cd8.app.goo.gl/B7vVu to a much more friendly https://mygame.page.link/mycampaign.
https://mygame.page.link/mycampaign
We're rolling out these changes after talking with many of you and running tests on how we could improve Dynamic Links. Through your feedback and our experimentation, we discovered three important things:
https://a7cd8.page.link/B7vVu
https://mygame.app.goo.gl/B7vVu
https://a7cd8.app.goo.gl/B7vVu.
https://a7cd8.app.goo.gl/mycampaign
With these results in mind, we are giving you the flexibility to use a brand agnostic root (page.link), create up to five custom subdomains per project, and create a custom path for each new short link. Now, you can have links that look like: mygame.page.link/joinme, mygame.page.link/holidays and mygame-lite.page.link/holidays.
page.link
mygame.page.link/joinme
mygame.page.link/holidays
mygame-lite.page.link/holidays
When you customize your dynamic links in these three ways, your brand will shine through, you will increase trust and conversion, and you'll be able to design links to better fit the context of where they are used.
Creating custom Dynamic Links is easy. There is a one-time setup process in the Firebase Console to set up your domain. Once that's done, you can create new links programmatically or via the console on your chosen domain.
If you're new to Dynamic Links, you'll be prompted to enter a custom subdomain during the setup process. For trademarked subdomains, we also have a verification flow to ensure that the subdomain is reserved for the developer that owns the brand.
For developers with existing Dynamic Links, you may continue to use links on app.goo.gl or create new links on page.link.
app.goo.gl
You'll be able to view the links and associated analytics per domain by selecting the domain from a drop-down selector.
For more information on creating Dynamic Links programmatically, see our documentation on iOS, Android and the REST API.
Thank you to everybody who has been using Dynamic Links and providing us with valuable feedback. We hope that these changes will result in more user engagement and more clicks on your dynamic links for your app.
If you have any questions, feedback or bugs to report please reach us at firebase.google.com/support.
Learn more about Firebase Dynamic Links at https://firebase.google.com/products/dynamic-links/.
On May 25, a new piece of European data protection legislation came into force: the General Data Protection Regulation, or GDPR.
We know that GDPR compliance is at the top of many of your minds, so we've been working hard over the past few months to ensure that you have the resources you need.
We updated to new, GDPR-friendly terms that includes the Firebase Data Processing and Security Terms. We've also given you a way to specify a Data Processing Officer (DPO) or EU Representative in the Firebase console. If you've already added your project's DPO or EU Rep in the Google Cloud console, you don't need to do it again for Firebase.
It's not just about the GDPR either - we've certified many Firebase products under security standards such as ISO 27001, ISO 27017, ISO 27018 and SOC 1, 2 and 3.
To help you implement privacy best practices we've added a dedicated Privacy and Security in Firebase section, launched a new guide on how to manage Instance IDs, and given you some suggestions on how to clear and export user data and store privacy settings using Firebase tools.
For Google Analytics for Firebase users, we have a new guide on your data management options, new sharing settings within the Firebase console that lets you have more control over your data, and a new API for deleting data associated with an Analytics App Instance ID.
Finally, you may want to check out our Google I/O session on paving the way to using Firebase within your enterprise for more ideas on how to manage user data:
If you have any further questions, don't hesitate to reach out to our support team—we can't offer legal advice, but we'll do what we can to help you out with any specific questions or technical concerns.
We have great news for web developers that use Firebase Cloud Messaging to send notifications to clients! The FCM v1 REST API has integrated fully with the Web Notifications API. This integration allows you to set icons, images, actions and more for your Web notifications from your server! Better yet, as the Web Notifications API continues to grow and change, these options will be immediately available to you. You won't have to wait for an update to FCM to support them!
Below is a sample payload you can send to your web clients on Push API supported browsers. This notification would be useful for a web app that supports image posting. It can encourage users to engage with the app.
{ "message": { "webpush": { "notification": { "title": "Fish Photos 🐟", "body": "Thanks for signing up for Fish Photos! You now will receive fun daily photos of fish!", "icon": "firebase-logo.png", "image": "guppies.jpg", "data": { "notificationType": "fishPhoto", "photoId": "123456" }, "click_action": "https://example.com/fish_photos", "actions": [ { "title": "Like", "action": "like", "icon": "icons/heart.png" }, { "title": "Unsubscribe", "action": "unsubscribe", "icon": "icons/cross.png" } ] } }, "token": "<APP_INSTANCE_REGISTRATION_TOKEN>" } }
Notice that you are able to set new parameters, such as actions, which gives the user different ways to interact with the notification. In the example below, users have the option to choose from actions to like the photo or to unsubscribe.
To handle action clicks in your app, you need to add an event listener in the default firebase-messaging-sw.js file (or your custom service worker). If an action button was clicked, event.action will contain the string that identifies the clicked action. Here's how to handle the "like" and "unsubscribe" events on the client:
like
unsubscribe
// Retrieve an instance of Firebase Messaging so that it can handle background messages. const messaging = firebase.messaging(); // Add an event listener to handle notification clicks self.addEventListener('notificationclick', function(event) { if (event.action === 'like') { // Like button was clicked const photoId = event.notification.data.photoId; like(photoId); } else if (event.action === 'unsubscribe') { // Unsubscribe button was clicked const notificationType = event.notification.data.notificationType; unsubscribe(notificationType); } event.notification.close(); });
The SDK will still handle regular notification clicks and redirect the user to your click_action link if provided. To see more on how to handle click actions on the client, check out the guide.
Since different browsers support different parameters in different platforms, it's important to check out the browser compatibility documentation to ensure your notifications work as intended. Want to learn more about what the Send API can do? Check out the FCM Send API documentation and the Web Notifications API documentation. If you're using the FCM Send API and you incorporate the Web Notifications API in a cool way, then let us know! Find Firebase on Twitter at @Firebase, and Facebook and Google+ by searching "Firebase".
