プログラミング学習

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

プログラミング学習

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

特集:Xserver VPS開始!マイクラや開発におすすめで安いVPSサーバー!

firebaseのプロジェクト作成

firebaseの登録

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

フロー配下のとおり。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

違いは? 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 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;

コメント