Here at Firebase, we want to make sure you and your users don't ever need to think about the dark underbelly of securing identities and managing users. That's why we're here! We've been hard at work making Firebase Authentication even better, and today I'd love to take you through some of the new functionality we've delivered in an effort to make registering and signing in users even easier.
We've heard loud and clear that our existing mail relay service wasn't providing the high standards you expect from Firebase. Over the last few months, we've not only rolled out the ability to configure your own custom SMTP server, but we've been working incredibly hard to move to a new, highly performant mail service, powered by Google. For more than 99% of Firebase Auth projects, we've performed this migration behind the scenes. Feedback so far has been resoundingly positive and we've heard from a lot of you that this has offered much-needed performance improvements. For our customers that have not yet made the move, we're excited to get you onto the new platform! You have received instructions on a manual verification step that needs to be taken, but if you're having any issues, please don't hesitate to reach out to support.
With this new functionality, your users will be able to seamlessly authenticate to your app simply by clicking a link in their email. No need to remember complex passwords or another set of credentials. We've worked really hard to ensure that users will continue to have the same level of security with an even better authentication experience, and we're excited to finally get this into the hands of our developers. I for one am glad to have one less password to remember!
This functionality is available now for Android, iOS and Web.
Using the Admin SDK, we've had the ability to add and evaluate custom claims in ID tokens for quite some time, as well as providing other useful claims in the ID token payload, such as expiration and issued-at time. We heard from many developers out there that you wanted to customize user experience on the client based on these claim values. Some interesting use-cases are around customizing look and feel based on a specific role or permission or showing additional features to administrators/managers. With that in mind, we've extended the flexibility of custom claims to enable you to consume these values directly from your client app.
We're excited about this change, but want to be sure we reiterate some of our best practices for custom claims:
Traditionally, Firebase Authentication sessions have lived on the client side with a short-lived authentication token (1 hour) and refresh token that was available indefinitely. Many of you out there have told us that you wanted far more granularity and control server-side as to how long a user's session could last. We heard your calls and want to ensure that you never have to go through the trouble of spinning up servers, databases and cryptography systems to roll your own session management system, so we've released this set of new controls directly inside of Firebase Authentication.
With this release, we introduce the capability to issue JWT-based session cookies from the Firebase Admin SDK. This will allow you to create session cookies with custom expiration times ranging from 5 minutes to 2 weeks and still retain all the benefits of custom claims client-side to provide logic and customization to your application.
We've got more details as well as samples of our session management capabilities available in our Admin SDK docs.
The Firebase Authentication team will be at I/O 2018, and we'd love to see you there! We're hosting Authentication Office Hours during the event, and the team will be there to take your questions, discuss some of our awesome new features, or even just to say hi. Look for more details closer to the event. We look forward to seeing you there.
In 2016, we unveiled Firebase Cloud Messaging (FCM) as the next evolution of Google Cloud Messaging (GCM). Since then, we've been working hard to make Firebase Cloud Messaging even more powerful than its predecessor. Like GCM, Firebase Cloud Messaging allows you to send notifications and data messages reliably to iOS, Android, and the Web at no cost. In addition, FCM includes a host of new features, such as an intuitive notifications interface in the Firebase console, better reporting, and native integrations with other Firebase products. With FCM, you can target and test notifications to re-engage your users with greater ease and efficiency.
We're excited to devote more time and attention to improving FCM. That's why today we're announcing that all developers will need to upgrade to FCM within a year. The GCM server and client APIs have been deprecated and will be removed as soon as April 11th, 2019. We recommend you upgrade sooner rather than later so you can start taking advantage of the new features we're building in FCM right away!
To help you through the upgrade, we've created a step-by-step migration guide and answered a few of the most common questions you'll probably have below.
What else is new in FCM?
Once you upgrade, you'll be able to use all of the new features and functionality available in FCM, like platform overrides and topic combinations. You'll also be able to send notifications directly from the Firebase console! What's more, FCM integrates seamlessly with other Firebase products like A/B Testing and Predictions.
Want to test different messages to see which one drives more conversions? You can use FCM with A/B Testing to run experiments to optimize your notifications. Want to engage users who are likely to churn or spend money in your app? You can use FCM with Predictions to target notifications to users based on their predicted behavior.
These are some of the awesome features you'll have at your fingertips with FCM. In the future, we'll be adding many more!
Will I still be able to send messages to my existing users?
If you have projects that are still using the GCM APIs, you will need to update your client and server code to use FCM before April 11, 2019. But rest assured, your existing GCM tokens will continue to work with FCM so you won't lose the ability to send messages to your existing users.
How do I upgrade?
The full process is outlined in our migration guide, or if you prefer video content, you can also check out this Firecast for details.
On a high level, upgrading consists of three main parts: console-side, app-side, and server-side.
Keep in mind that you don't have to complete all three parts of the process in one sitting - you can take it at your own pace. For example, you can choose to configure the console today and work on the app code another time. You're also free to update your app's code right now, and tackle the server-side requirements later.
What happens to my users who don't update their apps?
As long as users have GCM logic in their apps, they will still receive messages. FCM is backwards compatible with GCM, so even if you don't update your server endpoint now, you can still update your app's logic, and vice versa.
What data will Firebase collect and use? I'm concerned about privacy.
Please see the Firebase terms and the Firebase Privacy and Security Policy. You can disable Google Analytics for Firebase to reduce the amount of data that is collected, but keep in mind this will also disable some FCM features.
What if I still have questions?
We're here to help you through the upgrade process. Check out this nifty FAQ page as a start. We also encourage you to post your questions on StackOverflow. Or, feel free to reach out to Firebase support through any of these means.
To save you clicking time, here are some of the links that are also worth a read. Start with the upgrade guide, and then check out the other links to find out more.
What if I already migrated?
Awesome! How'd it go? Tweet me at @ThatJenPerson to tell me what went well and what didn't. Sharing your experience helps us make improvements!
We look forward to welcoming you to FCM, the next evolution of GCM!
The Firebase console gives you the power to make changes to your Cloud Firestore Security Rules directly from your browser! Unfortunately, that also means your team has the ability to break your security rules directly from your browser, maybe without remembering exactly what they changed. Well fear no more; Firebase has your back!
Recently, we added Version History to Cloud Firestore Security Rules. For any Cloud Firestore project, you can now browse all previously published versions of Rules, view the differences between the previous and current versions, and edit the current version -- either to a complete rollback to an earlier version or to a mix of rules.
Now, when your team introduces a bad security rule, it's a snap to find out what the previous working version was and get back to it.
To start using version history for Security Rules, simply navigate to the Rules tab of Cloud Firestore, and start browsing your version history in the left-hand column. From any older version, you can click "Compare to Latest" to view the diff and edit the latest version.
Every deploy that includes Rules is considered a new version; you'll see unchanged versions if you've deployed unchanged rules several times from the command line. To avoid that, you can call deploy --only from the Firebase CLI to deploy only the things you've changed. For example, I often make edits to my project's Cloud Functions without changing anything else, so I end up running firebase deploy --only functions from the command-line tool to make sure only the changes to my Cloud Functions get submitted.
deploy --only
firebase deploy --only functions
Reach out to us via Twitter @Firebase or via our other support channels to let us know what you think! We're looking forward to adding this to other Firebase features, and would like to get your feedback before we do.
Last year, we launched the beta of Cloud Functions for Firebase to help you build backend functionality for your app without worrying about managing servers. It lets you write in JavaScript or Typescript, deploy to Google's Cloud infrastructure, and execute in response to app events. Today we're pleased to release version 1.0 of the Cloud Functions for Firebase SDK - along with new, frequently requested improvements for the development, testing and monitoring of Functions.
The Firebase SDK for Google Cloud Functions enables you to extend other Firebase products, giving users the features they need in your apps. One of our earliest customers, Posse, makers of the Hamilton app, needed to create a lottery system to give fans a chance to win tickets to the massively popular Broadway play - without the overhead of managing their own servers. When a user enters the lottery, Functions powered logic runs in the cloud with results stored directly to Cloud Firestore. Lottery results are pushed automatically to lucky fans' Hamilton mobile app.
Posse also needed to scale the Hamilton app. When the lottery opens, the app's usage can suddenly surge multifold before normalizing a few minutes later. Functions automatically scales without needing any action from Posse, and their client only pays for the resources they use.
In addition to ticket lotteries, Posse also used Functions to integrate with other Firebase products to:
There's a great deal of things you can do with Functions. For more use cases and sample code, see our popular GitHub repo.
Today's v1.0 release comes with a number of new features based on your feedback - here's the lowdown!
One of your biggest requests was for an easy way to directly call Functions from your client apps. To facilitate that, we're adding a new type of function, along with SDKs for iOS, Android, and web clients. The new type is a Callable HTTPS function that manages an HTTPS request from the client SDK. Callable HTTPS functions drastically reduce the amount of boilerplate code you have to write to make HTTPS requests to Functions.
Here's how it works:
For more, check out our docs!
While Functions Shell gave you the ability to interact with your functions locally, it was not optimal for writing unit tests such as those that run in a CI system. That's why we are launching a new firebase-functions-test npm module that simplifies writing unit tests. firebase-functions-test takes care of the necessary setup and teardown, allowing easy mocking of test data. Now, you can either write completely offline tests that have no side effects, or tests that interact with a development Firebase project - where you can observe the success of actions such as database writes.
Last fall, we introduced the ability to emulate your functions locally via the Firebase CLI through both the "firebase serve --only functions" and "firebase experimental:functions:shell" command. These were experimental features, and now we are officially supporting them. "firebase experimental:functions:shell" has been renamed to "firebase functions:shell", and "firebase serve" will emulate all HTTPS functions by default without the need for the "--only" flag.
After deploying functions, you may be wondering: "What's happening with my functions? How is my app performing? Is anything broken?" With today's release, you can now keep tabs on any errors in your functions via the new health monitor:
Additionally, you can track your functions' performance, latency and memory usage:
The APIs for writing Cloud Functions with the Firebase SDK have changed in this v1.0 SDK release. This means that upgrading to the new SDK will require some updates to any code you've already written during the beta. But don't worry - this doesn't affect any functions you have already deployed. To see what has changed and how to adapt to the new format, just follow our migration guide!
If you're just getting started with the Firebase SDKs for Cloud Functions, try following our step-by-step Codelab and visiting the documentation. There is also a video tutorial to help get you set up using TypeScript as the recommended programming language.
We hope you find these new features helpful. While the Firebase SDKs for Cloud Functions are fully released, the Cloud Functions platform is still in beta. Stay tuned for more updates!
