0

これは主に言葉遣いの問題です。しかし、非常に重要なものですが、それはさらに大きなチームによって維持されている大きなコードベースで起こりうる誤解を引き起こす可能性があります。認証システムを備えた非常に基本的なCRUD/RESTfulアプリがあるとしましょう。この場合、データ変更要求（POST / PUT）を実行しようとしている認証済みユーザーは、サーバーによって識別され（認証）、この識別されたユーザーがリソースを作成/更新する権利を持っているかどうかがチェックされます。質問（認証）。

ここで、Oauthプロトコルを実装して、後の段階で何らかのWebAPIソリューションをサポートするとします。この場合、クライアントアプリAのユーザーは、何かを行うためにリソースプロバイダーに承認を求める必要があります。

そのため、現時点では、同じアプリ内に2つの有効な承認の概念があります。アプリケーションレベルでは、2つの概念を関連する名前空間で囲むことができるため、それほど大きな問題ではありませんが、DBには、名前の承認を共有できない2つの有効な候補があります。

私は名前空間テーブル名の大ファンではないので、そのうちの1つ（または実装した可能性のある他のワイルドなソリューション）の名前を変更するための提案をしたいと思います。

Cheerio

4

1 に答える 1

1

よりわかりやすい名前を oauthgrantsプレフィックスとして付けることはどうですか?: と. これは名前空間に関するルールに違反する可能性がありますが、より説明的になります。 authorizationsuser_authorizationsapp_user_authorizations

user_authorizationsまたはauthorizations、システム内でユーザーが許可されていることを行うだけです。

app_user_authorizationsまたはoauthgrants、ユーザーが OAuth を介してサードパーティのアプリケーションに付与した権限を持っている可能性があります。ユーザー ID、OAuth 2.0 クライアント ID、付与されたスコープ、更新トークン (存在する場合)、有効期限 (存在する場合) が格納されます。実装方法によっては、アクセス トークンが含まれる場合もあります (または、別のテーブルにある場合や、暗号的に検証可能なため格納されていない場合もあります)。

于 2012-09-09T00:39:21.937 に答える