This guide covers basic aspects on how to use Firebase in your plugins. For a complete reference or tutorials, checkout the links in the bottom of this page.
After creating an app in Firebase, go to the settings section in the Developer Tools and save the URL and secret of your Firebase app. To initialize Firebase from your plugin frontend, inject the $firebase service in the controllers, services, factories or directives signature, create a reference to your Firebase URL and assign it to the scope:
Adding data to a list
The $add method takes a single argument of any type. It will append this value as a member of a list.
Adding or Updating keys
The $update method takes a single argument of any type. It will append or update existing keys.
The $remove method takes a single optional argument, a key. If a key is provided, this method will remove the child referenced by that key.
To get advantage of the already logged in user in Zengine and authenticate this same user in Firebase, you need to use the custom login method, this method uses a JWT token instead of a username and password.
You can get a token to authenticate the current user in Firebase by fetching your plugin data using the Data factory. The response will contain a firebaseAuthToken attribute, which is generated using the Firebase secret that you set in your “Plugin Settings”.
The example below demonstrates how you can fetch the current plugin and user data from Zengine API, and then use it to connect to Firebase.
Using the Firebase dashboard, you can setup security rules to define when your data can be read from and written to.
The workspaces object contains all of the workspaces the currently authenticated user is a member of, where each key is the workspace id and the corresponding value is the user’s role in that workspace.
Now we’ll show how you can use this auth variable in your security rules. In the example below, the reference https://<my-firebase>.firebaseio.com/preferences/<user-id> is a list of preferences of a specific user id. The rules below allow read and write access only if the currently authenticated user id matches the <user-id>.
Another example is restricting read access to any user belonging to the workspace and write access to workspace owners, assuming the following reference to https://<my-firebase>.firebaseio.com/preferences/<workspace-id>
When using the znFirebase wrapper with a Backend service, znFirebase will automatically authenticate and the following data will be available with the auth variable in your security rules, assuming the request was made to a backend service at https://plugins.zenginehq.com/workspaces/1/testBackendService/testRoute:
Similar to the authentication data from the frontend, the auth data from the backend contains a workspaces object. However, for backend service Firebase authentication, the workspaces object contains a single key-value pair: the workspace id which the backend service request was made against and the value server.
With this, you can extend your security rules to also allow backend service access. We will expand on the previous example to also allow read and write access to backend services: