firebase storageやfirestoreのルールの書き方・設定

主にfirebaseのfirestoreやstorageルール覚書です。

firebaseのプロジェクト作成

firebaseの登録

googleのアカウントでログインするだけです。

フロー配下のとおり。

使っているgmailでログイン > プロジェクトを作成

• 「プロジェクト名」を入力して続行
• プロジェクトIDも変更(TwitterのIDのように、すでに人と重複したものはダメ!)

「このプロジェクトで Google アナリティクスを有効にする推奨」をチェックオンにして続行

Google アナリティクスの構成 > 「新しいアカウントを作成」 名前を入力して保存 > アナリティクスの地域 日本　他にチェックをいれてチェックをいれて「プロジェクトを作成」

ブログなどで利用している場合、既存のものがあれば割り当てできますが、新しく作成した方がよさそうです。

コンソールに移動 > プロジェクト名 > database > データベースの作成

• 本番環境モードで開始する(慣れていたらこちら!ルールの設定が必要)
• テストモードで開始する(30日間は「すべての読み取り/書き込みを許可」。Firebaseをはやく試してみたい人はこっちでもいいけど、問題の先送りをしているだけなので30日後にルールの設定が必要)

Cloud Firestore のロケーション asia-northeast1（東京)

(追記)場所が増えましたかね

• asia-northeast2（大阪)
• asia-northeast3（ソウル)

注意事項が表示されます。

firebaseのデメリットだった、リージョン問題が解決!

久々にぐぐったら、変化があったようです。この問題に関する解決方法が提示されていました(未検証なのでリンク先などを参考にどうぞ!)以前、この問題に頭を悩ませていたのでよかったですね！

長い間、Firebaseで動的コンテンツを扱う場合、FunctionsのRegionが指定できずus-central1しか使えないとい成約がありました。この為、動的コンテンツは米国サーバを使うことになり日本からアクセスする場合に、遅延が避けられない問題がありました。

https://zenn.dev/singularity/articles/firebase-hosting-region

(過去記事)リージョンの変更はできないけどOGPの対応でもやもやするものが残りますね。

モバイルアプリとかでFunctions使う場合は断然asia-northeast1だと思うけどWebだとFunctionsもcentral1のほうがいいのかな～。ただfirestoreはasia-northeast1に置いたりするとちぐはぐになっちゃう

— たる (@tarumzu) August 2, 2020

動的OGPを作る上で、asia-northeast1でFunction作ってたらうまくいかなかったのでよく見てみたらこんな記述があってハマった…

>重要: HTTP 関数を使用して Firebase Hosting の動的コンテンツを提供する場合は、us-central1 を使用する必要があります。https://t.co/BOhoiB1U9X

— NAKAJIMA ( nice2have ) 🐳 Solo Indie Developer (@jnakajima1982) March 9, 2022

nextjs+firebase(hosting,firestore, functions)の構成が一番ラクなんだけど、SSRまでやるとfunctionsのリージョンがus-central1になっちゃうので、その辺りどうしようかなって思ってる。

— にるぽ犬 (@anoChick) September 11, 2021

Firebaseを日本のサーバーで稼働させる為に、Cloud Functionsのロケーションを変更しても、Firebase.jsonのrewriteで自動的に‘us-central1’に戻ってしまう問題。
Google側は優先度の問題で着手できないらしいので、現状はサポートに依頼して1票を投じるしかない模様。
とりあえず1票入れました。 pic.twitter.com/tipZLkSzxP

— MK（ツケアワセドットコム）🍳料理と風景撮影好き (@tsukeawase1013) June 5, 2020

違いは? Realtime DatabaseとCloud Firestoreの比較

データベースが2つあり、どっちにしようか迷うかもしれません。

簡単にいうとRealtime DatabaseよりCloud Firestoreの方が新しいためCloud FirestoreでOKです。詳しい比較表はQiitaをみましょう。

https://qiita.com/Yatima/items/54ea22d0cea1acc6cbcb

firebaseのfirestoreやstorageルールの書き方・設定

違いは?テストモードとロックモードの比較

テストモードにしとけという人とロックモードにしとけという人、この2つのリファレンスがあってちょっと迷うかもしれません。ソースコードをみると全拒絶か全オープンかどちらかであり単純にそれだけです。セキュリティ等に関する各々の考え方の違いから、どちらかを推奨するかがエンジニアさんによって違うみたいな感じですかね。

テストモードはallowになっています。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {

    // This rule allows anyone on the internet to view, edit, and delete
    // all data in your Firestore database. It is useful for getting
    // started, but it is configured to expire after 30 days because it
    // leaves your app open to attackers. At that time, all client
    // requests to your Firestore database will be denied.
    //
    // Make sure to write security rules for your app before that time, or else
    // your app will lose access to your Firestore database
    match /{document=**} {
      allow read, write: if request.time < timestamp.date(2020, 1, 16);
    }
  }
}

テストモードの場合は30日間オープンになるため、30日の猶予があります。それ以降は警告メールがきます。

ロックモードはallowがfalseになっています。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if false;
    }
  }
}

どちらも仮であり、どのみち書き換えなければなりません。この書き換え方が大事ですよね。

認証した人の制限をつけます。いたずらなどの負荷回避にもなります。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read, update, delete: if request.auth.uid == userId;
      allow create: if request.auth.uid != null;
    }
  }
}

公式サイトにのっています。

https://firebase.google.com/docs/firestore/security/rules-conditions?hl=ja

階層を掘るとこうなります。

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId}/address/{addressId} {
      allow read, update, delete: if request.auth.uid == userId;
      allow create: if request.auth.uid != null;
    }
  }
}

firestoreのルールの認証の未認証の切り分け

次のようにすると、ログイン済ならnull以外になるためreadとwriteできます。ログアウト時はreadのみです。

match /users/{userId} {
  allow read, write: if request.auth.uid != null;
  allow read;
}

firebase storageのルールの書き方サンプル

readは登録前のユーザーに許可して、アップロードなどのwriteはログインユーザーのみ許可する例です。

rules_version = '2';
service firebase.storage {
  match /b/{bucket}/o {
    match /{allPaths=**} {
      allow read: if true;
      allow write: if request.auth != null;
    }
  }
}

firebase storageのルールの書き方サンプル(認証なしでもありでも使えるサービス)

少し複雑な場合を想定しましょう。

登録なしのユーザーも登録ありのユーザーも利用できるサービス。管理者が管理するブログが併設しているとします。フォルダ構成は次のようにします。

- unregistered
  - image
- registered
  - image
- blog
  - categoryA
  - categoryB

ルールはこうです。

service firebase.storage {
  match /b/{bucket}/o {
    match /unregistered/image/{allPaths=**} {
      // 一時的に読み書きを許可 (あとでCloud Functionsなどで定期削除)
      allow read, write: if true;
    }

    match /registered/image/{allPaths=**} {
      allow read, write: if request.auth != null;
    }

    match /blog/{category}/{allPaths=**} {
      allow read: if true;
      allow write: if request.auth != null;
    }
  }
}

firebaseのルールの設定を忘れて起こるエラー

Firebase Storage: User does not have permission to access

Firebase Storage: User does not have permission to access

たとえば、Storageに画像をアップロードしようとした場合、readだけの場合、このエラーがでます。writeを許可しましょう。

下記はログイン時だけ許可した例です。

allow read, write: if request.auth.uid != null;