Run any DB request as a Firebase app's end-user

Thanks for stopping by to let us know something could be better!

PLEASE READ: If you have a support contract with Google, please create an issue in the support console instead of filing on GitHub. This will ensure a timely response.

Is your feature request related to a problem? Please describe. Hi, security rules are amazing. Its too bad they only work for client side code. On Node.js (server side code), I have to roll my own security rules.

Describe the solution you’d like I should be able to run database request as the applications end user.

On the client-side, Firebase makes use of the app’s end-user’s JWT. That information is used to match against security rules. On the server-side, you should allow a user to pass their end-user’s JWT to Firestore. The JWT can then be processed, along with the resource, to check against security rules to ensure this app’s end user has read / write access to the resource. It’d be simple to do this. We just need one more argument, the end user’s JWT.

For example:

const Firestore = require('@google-cloud/firestore');

async function main( req, res ) {
    const firestore = new Firestore();
    const endUserJWT = req.jwt // given we have access to the end-user's JWT, which is by defintion a custom Firebase JWT , or the actual firebase JWT, then lets make a variable out of that

    const document = firestore.doc('posts/intro-to-firestore');
    console.log('Document created');
 
    // Enter new data into the document.
    await document.set({
      title: 'Welcome to Firestore',
      body: 'Hello World',
    }, endUserJWT );
    console.log('Entered new data into the document, accepted if UID is allowed to write, rejected otherwise');
 
    // Update an existing document.
    await document.update({
      body: 'My first Firestore app',
    }, endUserJWT );
    console.log('Updated an existing document, if this UID is allowed to update');
 
    // Read the document.
    let doc = await document.get( endUserJWT );
    console.log('Read the document, if the UID is allowed to read this resource');
 
    // Delete the document.
    await document.delete( endUserJWT );
    console.log('Deleted the document, if the UID is allowed to delete this resource');
 
};
 
main().catch(console.error);

This simple setup takes an optional second parameter, endUserJWT. The Firestore libabry can act as normal – if no JWT is provided, universal access is granted, if a JWT is passed, run the request against security rules.

Suddenly, security rules work on the client-side (thanks to JWT access) and server-side (thanks to JWT access), lol.

Describe alternatives you’ve considered I have to roll my own security rules, which is a hassle, but I’m doing this now. Its a no brainer to add this feature to radically simplify Firestore dev’s lives. Additional context

[lookfirst]

I would love to be able to use the Admin SDK as a specific user on a per request basis.

[NawarA]

This is actually a really easy feature for the Firestore team to add.

As I mentioned earlier on this thread, to make this work, on the backend just allow dev’s to pass in the user’s JWT to the DB action.

let doc = await document.get( endUserJWT );

If endUserJWT is undefined, Firestore grants universal access (what we have today). If it is defined and the JWT is a valid client-side generated JWT that represents a user, then the Firestore checks its security rules to ensure the users is allowed to the do the action.

This feature is easy to add and maintain for the FS team (ie. its a very isolated service) and allows the firestore community to use security rules on the backend (which is important).