FirestoreでドキュメントIDとは別に、ユーザ作成のdisplayIDを作成する手法

Question

FirestoreにドキュメントIDとは別に、もう一つユーザが作成するdisplayIDを保存したいと思っています。
このIDは作成後の編集は出来ないようにする予定ですが、後々、編集機能をつけたくなる可能性もあるものです。
Twitterの@IDのようなもので、小文字と大文字は見分けません。

ドキュメント例
/users/{uid}
{
"displayId":"CatIsVeryCute",
"description":"Cat lover.",
"createTime":ServerTimestamp
}

現状、ドキュメントに
"lowerCaseDisplayId":"catisverycute",
のように、小文字のフィールドを追加し、クライアント側で

        let lowerCaseDisplayId = "CatIsVeryCute".lowercased()
        let docRef = db.collection("users").whereField("lowerCaseDisplayId", isEqualTo: lowerCaseDisplayId)
        docRef.getDocuments { (snapshot,  error) in
            if let error = error {
                // エラー処理
                return
            }
            if snapshot?.documents != []  {
                // 既存のIDだから、他のIDを作成してください！
                return
            }else{
                // 使えるIDです！
                return
            }
        }

と確認処理をさせて、サーバ側では、セキュリティルールで確認しようとしたのですが、セキュリティルールで確認する方法が見つかりませんでした。

そこで、今後の策としては
0. lowerCaseDisplayIdをドキュメントIDにして、セキュリティルールのexists()で確認
一意性は保証される。しかし、あとで変える機能が欲しくなった場合には苦労する。また、ユーザ作成なので、ホットスポットの要因になる可能性がある？
\n
0. Callable Functionsで確認・作成する
マルチスレッド処理なので、精密には一意性を保証できないが、クライアントだけの確認より、悪意を持って確認処理をしないで作成することができない分、マシなはず。。。
\n
0. クライアントだけの確認で妥協する
普通に使っている分には、ほぼ大丈夫な気がするが、悪意を持って同じIDを作成することは可能。クライアント側で、createTimeが古いユーザを表示するようにすれば、問題にならないかも？

の３つを考えています。

どれがいいか悩んでおり、アドバイスをいただければ幸いだと思っております。

また、セキュリティルールだけで一意性を保証できる方法をご存知の方は、ご教授いただけると大変ありがたいです。

よろしくお願いいたします。

Answer 1

正解はないと思いますがアドバイスとして。

lowerCaseDisplayIdをドキュメントIDにして、セキュリティルールのexists()で確認

一意性は保証される。しかし、あとで変える機能が欲しくなった場合には苦労する。

これに対してですが以下が良いと思います。

1. usersコレクションとは別に、displayIdだけを管理するdisplayIdsといったようなルートコレクションを作成する

2. displayIdsに対してセキュリティルールを設定する。

match /users/{userID} {
allow update: if request.auth.uid == userID
 &&
 (
 request.resource.data.displayId == resource.data.displayId
 ||
 !exists(/databases/$(database)/documents/displayIds/$(request.resource.data.displayId))
 );
}

あとは、クライアント（またはFunctions）からdisplayIdを登録・更新する際に、トランザクションの中でざっくりにはなりますが次の処理を行えば良いかと思います。

1. displayIdsに対してdisplayIdの存在確認　→　存在しなければ２へ
2. 更新の場合、displayIdsに対して変更前のdisplayIdを削除＆変更後のdisplayIdを登録
3. usersに対してdisplayIdを登録・更新

Comments

[wine]

一意性をexists()で確保しつつ、usersのドキュメントIDは固定になるため、変更しやすいまま実装できる訳ですね。

一意性確保を主眼として１つのルートコレクションを作成するという手法は、一見するだけでは無駄が多く感じられて、ほぼ考えることも出来なかったため、大変勉強になりました。

聞いてみると、最良の方法という気がしますし、視野を広く持って考えなければと反省しました。

この方法で実装しようと思います。

ありがとうございました！

[xenbeat]

????