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

プログラミング学習

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

特集:フリーランスWebエンジニアのための週2からのリモートワーク

firebaseのプロジェクト作成

firebaseの登録

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

フロー配下のとおり。

使っているgmailでログイン > 新しいプロジェクト > 「プロジェクト名」を入力して続行 > 「このプロジェクトで Google アナリティクスを有効にする推奨」をチェックオンにして続行 > Google アナリティクスの構成 > 「新しいアカウントを作成」 名前を入力して保存 > アナリティクスの地域 日本　他にチェックをいれてチェックをいれて「プロジェクトを作成」

コンソールに移動 > プロジェクト名 > database > データベースの作成 > テストモードで開始(もしくは本番環境で開始) > Cloud Firestore のロケーション asia-northeast1（東京)

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

設定後にこのロケーションを変更することはできません。また、このロケーション設定は、デフォルトの Cloud Storage バケットのロケーションになります。

リージョンの変更はできないけど

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

firebaseのデメリットです。

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

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

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

Firebase RTDB + GCP datastore = Firestoreについて第一印象 - Qiita
ほぼ一日経っても誰もまだQiitaに投稿してないんで，ひとまずざっくり記しときます．　tl;drまじやばいぐうぐるの超技術が超手軽に ←まじやばい追記：すごさについて @1amageek 氏がまとめてくれてます．なん...
qiita.com
スポンサーリンク

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;
    }
  }
}

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

Cloud Firestore セキュリティ ルールの条件の記述  |  Firebase
firebase.google.com

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

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;

コメント