ユーザーの内部IDの発行権を他人に握らせてはいけない - kosui

結論 ユーザーの内部IDを自システム以外に委ねるべきではありません。 ユーザーの内部IDの実装について気をつけるべきことを2つ紹介します。 外部サービスが発行したIDを内部IDにするべきではない ユーザーが変更可能な値を内部IDにするべきではない 外部サービスが発行したIDを内部IDにするべきではない 外部サービスが発行したIDを内部IDにすることは避けましょう。 内部IDは、システム内で一意で永続的な識別子であるべきです。 例) 外部IDプロバイダのユーザーID 例えば、GoogleをIDプロバイダとして利用する上で、GoogleアカウントのユーザーIDをそのままユーザーの内部IDとして使用した場合、どんな問題が起こるかを考えてみましょう。 例えば、後からGoogleがユーザーIDの仕様を変更した場合、システム内でのユーザーIDの一意性が保証されなくなります。もちろん、Googleがユー

[nakag0711]

AWSってユーザーが指定した文字列をそのまま内部IDに使うもんだから後から変更できないの多いんだよな

[yamadadadada2]

マルチテナントでこの辺の設計ミスってつらくなる事例がゴロゴロ

[hachi]

タイトルは鬼滅の刃のアレよね

[tmatsuu]

せやな。せやせや。特に最後にある退会後の乗っ取り対策を忘れないよう。

[tmtms]

利用者の目に見えて意味のあるような文字列をDBの主キーにしてはいけないというやつだな

[cocelo]

これはその通りすぎる。システム設計やったことない人には伝わりづらいのが難しいところよね…生殺与奪の権もその通り過ぎて笑ってしまった

[retore]

subを使うようにしろって話ではなく？

[romsentan]

お前のオールを任せるな

[roshi]

前にUUIDをDBの主キー値に使っているシステムで、クライアント側で生成したUUIDをそのまま使う実装に遭遇したことある。

[atsushifx]

内部IDは、システム内で一意で不変であるべきというのが基本で、ユーザー名やEメール、OpenIDなどはリレーションでという主張

[taguch1]

結構よく見かけるアンチパターン。システムを引き継いだ瞬間いつか来る大改修に震える。

[clclcl]

生殺与奪の権