Auth Variable

If the client trying to read or write has authenticated with a valid auth token, the auth payload will be stored in a variable called auth. The contents will depend on how the auth token was generated. If the client is not authenticated, the auth variable will be null.

Auth Payload for Custom-generated Tokens

If you generated the token using one of our Token Generator Libraries, the contents of auth will be whatever JSON you passed to createToken(). For example if you created a token using the following snippet:

var FirebaseTokenGenerator = require("./firebase-token-generator-node.js");
var tokenGenerator = new FirebaseTokenGenerator(YOUR_FIREBASE_SECRET);
var token = tokenGenerator.createToken({"app_user_id": 1234, "isModerator": true });

Then you could use auth.app_user_id and auth.isModerator inside your rule expressions, for example to give users ability to create comments with their own userid, as well as for "moderators" to modify any user's comments:

{
  "rules": {
    ".read": true,
    "$comment": {
      ".write": "(!data.exists() && newData.child('user_id').val() == auth.app_user_id) || auth.isModerator == true"
    }
  }
}

If you provide null or an empty object for the first argument of createToken(), then the auth variable will be null in your rules.

Auth Payload for Firebase Simple Login: Email / Password

After authenticating using Email / Password Authentication, the auth variable will contain:

  • provider - The value will always be 'password'.
  • id - The unique id for the logged in user.

So for example, we could have a rule like the following to allow users to create comments as long as they store their user id with the comment:

{
  "rules": {
    ".read": true,
    "$comment": {
      ".write": "!data.exists() && newData.child('user_id').val() == auth.id"
    }
  }
}

Auth Payload for Firebase Simple Login: Facebook

After authenticating using Facebook Authentication, the auth variable:

  • provider - The value will always be 'facebook'.
  • id - The logged in user's facebook id.

So for example, we could have a rule like the following to allow users to create comments as long as they store their facebook id with the comment:

{
  "rules": {
    ".read": true,
    "$comment": {
      ".write": "!data.exists() && newData.child('facebook_id').val() == auth.id"
    }
  }
}

Auth Payload for Firebase Simple Login: Twitter

After authenticating using Twitter Authentication, the auth variable will contain:

  • provider - The value will always be 'twitter'.
  • id - The logged in user's twitter id.

So for example, we could have a rule like the following to allow users to create comments as long as they store their twitter id with the comment:

{
  "rules": {
    ".read": true,
    "$comment": {
      ".write": "!data.exists() && newData.child('twitter_id').val() == auth.id"
    }
  }
}

Auth Payload for Firebase Simple Login: Persona

After authenticating using Persona Authentication, the auth variable will contain:

  • provider - The value will always be 'persona'.
  • email - The logged in user's verified email address.
  • id - The user's escaped email address, suitable for use as a Firebase child name.

For example, we could create rules as follows to enforce per-user data buckets (users are only allowed to write in their own location):

{
  "rules": {
    ".read": true,
    "$user": {
      ".write": "auth.id == $user"
    }
  }
}