Search code examples
firebaserestgoogle-cloud-firestorefirebase-hosting

REST authorization with no user concept


Is there any way to do some kind of authorization that allows only people who recently requested a page from Firebase Hosting to be able to send an HTTP POST request to a Firestore db and have it go through?

My page is basically an HTML form that posts data to a Firestore page, though it would be nice if at least one had to speak with the server beforehand, as people do not have to log in to post information.

[EDIT] Requirements:

  • Serve a static HTML form (with some Javascript included)
  • The contents of the HTML form should be posted to a firestore database only if the client actually requested a page from the server within a reasonable timeframe
    • In general, some external code that did not recently request the page should not be able to post data to the database. This is just a minor restriction to mitigate any "attacks" being too easy.
  • No concept of user or login
  • All requests should be done through REST as including the Firebase SDK is way too large for this small of a project

Solution

  • With Firebase Hosting, there is no out-of-the-box logging mechanism that would allow detecting if a user has previously requested a page. You need a more "sophisticated" approach.

    I can see two possible approaches. (There might be other ones!)

    Approach #1 Use two Cloud Functions to:

    1. Serve the page via Firebase Hosting, see Serve dynamic content and host microservices with Cloud Functions
    2. Write to Firestore, after you have verified the user has previously requested a page.

    More details:

    For the first part, you will not actually serve dynamic content (I understand you plan to serve static pages through Hosting), but because this page is served through a Cloud Function, you will be able to save a unique token (e.g. a Firestore doc ID or any other UUID value) in, for example, Firestore, before sending back the page content.

    Then, for the second part (writing to Firestore), the Cloud Function will first check that there is a document with the doc ID previously generated in the Firestore database, and if it is the case, will allow the write to the database (from the Cloud Function).

    So, in this case, both Cloud Functions need to be HTTPS ones. You may be interested by this article which details the drawbacks of writing to Firestore through a CF.


    Approach #2 Use Firestore security rules for the check before writing.

    1. Do the same than the previous solution for serving the static pages;
    2. Write directly to Firestore and implement a security rule that checks for the existence of a Firestore document with the doc ID saved in point 1. See the exists method.