主にfirebaseのfirestoreやstorageルール覚書です。
firebaseのプロジェクト作成
firebaseの登録
googleのアカウントでログインするだけです。
フロー配下のとおり。
使っているgmailでログイン > 新しいプロジェクト > 「プロジェクト名」を入力して続行 > 「このプロジェクトで Google アナリティクスを有効にする推奨」をチェックオンにして続行 > Google アナリティクスの構成 > 「新しいアカウントを作成」 名前を入力して保存 > アナリティクスの地域 日本 他にチェックをいれてチェックをいれて「プロジェクトを作成」
コンソールに移動 > プロジェクト名 > database > データベースの作成 > テストモードで開始(もしくは本番環境で開始) > Cloud Firestore のロケーション asia-northeast1(東京)
注意事項が表示されます。
リージョンの変更はできないけど
リージョンの変更はできないけどOGPの対応でもやもやするものが残りますね。
モバイルアプリとかでFunctions使う場合は断然asia-northeast1だと思うけどWebだとFunctionsもcentral1のほうがいいのかな~。ただfirestoreはasia-northeast1に置いたりするとちぐはぐになっちゃう
— たる (@tarumzu) August 2, 2020
動的OGPを作る上で、asia-northeast1でFunction作ってたらうまくいかなかったのでよく見てみたらこんな記述があってハマった…
— NAKAJIMA ( nice2have ) 🐳 Solo Indie Developer (@jnakajima1982) March 9, 2022
>重要: HTTP 関数を使用して Firebase Hosting の動的コンテンツを提供する場合は、us-central1 を使用する必要があります。https://t.co/BOhoiB1U9X
nextjs+firebase(hosting,firestore, functions)の構成が一番ラクなんだけど、SSRまでやるとfunctionsのリージョンがus-central1になっちゃうので、その辺りどうしようかなって思ってる。
— にるぽ犬 (@anoChick) September 11, 2021
Firebaseを日本のサーバーで稼働させる為に、Cloud Functionsのロケーションを変更しても、Firebase.jsonのrewriteで自動的に‘us-central1’に戻ってしまう問題。
— MK(ツケアワセドットコム)🍳料理と風景撮影好き (@tsukeawase1013) June 5, 2020
Google側は優先度の問題で着手できないらしいので、現状はサポートに依頼して1票を投じるしかない模様。
とりあえず1票入れました。 pic.twitter.com/tipZLkSzxP
firebaseのデメリットです。
違いは? Realtime DatabaseとCloud Firestoreの比較
データベースが2つあり、どっちにしようか迷うかもしれません。
簡単にいうとRealtime DatabaseよりCloud Firestoreの方が新しいためCloud FirestoreでOKです。詳しい比較表はQiitaをみましょう。

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; } } }
どちらも仮であり、どのみち書き換えなければなりません。この書き換え方が大事ですよね。
- アクセス権限はreadとwriteに大別されます。
- readはget、listにわけられます。
- writeはcreate、update、 deleteにわけられます。
認証した人の制限をつけます。いたずらなどの負荷回避にもなります。
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; } } }
公式サイトにのっています。
階層を掘るとこうなります。
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のルールの設定を忘れて起こるエラー
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;
コメント