19

DevDefinedライブラリを使用してOAuthプロバイダーを実装しています。

サーバー側にコンシューマーデータとトークンデータを格納するための推奨データベース構造はあるのでしょうか。

これに関するアドバイスをいただければ幸いです。

4

2 に答える 2

28

注意：以下の答えは主にOAuth1.0に当てはまります

DevDefinedライブラリについては何も知りません。しかし、これは、SQLデータベースを使用して、最新のプロジェクトで作業することになったデータベース設計の非技術的な説明です。

基本仕様に従うために必要なすべてをカバーする必要があります。私はそれを絶対的な最小値に抑えようとしました。

RequestTokens

  • トークン（ここではMD5、主キーを使用します）
  • ConsumerKey（コンシューマーの一意の識別子）
  • シークレット（SHA1）
  • createTime（タイムスタンプ）
  • 折り返し電話

AccessTokens

  • トークン（MD5、主キー）
  • シークレット（SHA1）
  • 消費者キー
  • userID（リソース所有者を参照）
  • createTime

消費者（登録済みのサードパーティアプリケーション）

  • ConsumerKey（MD5、主キー）
  • ConsumerSecret（SHA1）
  • userID（一意ではなく、アプリケーションを登録した開発者を指します）
  • 説明（アプリケーションを説明するテキスト）
  • name（アプリケーションの名前）
  • 折り返し電話

UsedNonces

  • ノンス
  • タイムスタンプ

ノンスの取り扱いは、私にとって本当に最大の設計上の質問でした。OAuthは、同じタイムスタンプで同じナンスを使用することを二度と許可しないように指示します。しかし、それは無限に巨大なデータベースになります。ほとんどのプロバイダーは、少なくとも時々古いナンスをバッチ処理すると思います。

タイムスタンプが5分を超えるすべてのリクエストが拒否されるという前提に基づいて、5分を超えるナンスを定期的に削除します。タイムスタンプをチェックするときは少し寛容です。タイムスタンプはUTCであり、5分以上である必要があり、サーバーの時刻より1分以上進んでいない必要があります。

于 2010-12-30T23:32:04.840 に答える
3

これにアプローチする方法はいくつかあります。プロバイダーとコンシューマーの両方の機能を実装するアプリケーションの一例は、AtlassianのJiraです。その構造は次のとおりです。

    <prim-key field="id"/>

    <index name="oauth_consumer_token_key_index" unique="true">
        <index-field name="tokenKey"/>
    </index>
    <index name="oauth_consumer_token_index">
        <index-field name="token"/>
    </index>
</entity>

 <entity entity-name="OAuthConsumer" table-name="oauthconsumer" package-name="">
    <field name="id" type="numeric"/>
    <field name="created" type="date-time"/>
    <field name="name" col-name="consumername" type="long-varchar"/>
    <field name="consumerKey" type="long-varchar"/>
    <field name="service" col-name="consumerservice" type="long-varchar"/>
    <field name="publicKey" type="very-long"/>
    <field name="privateKey" type="very-long"/>
    <field name="description" type="very-long"/>
    <field name="callback" type="very-long"/>
    <field name="signatureMethod" type="short-varchar"/>
    <field name="sharedSecret" type="very-long"/>

    <prim-key field="id"/>

    <index name="oauth_consumer_index" unique="true">
        <index-field name="consumerKey"/>
    </index>
    <index name="oauth_consumer_service_index" unique="true">
        <index-field name="service"/>
    </index>
</entity>

<!-- OAUTH ServiceProvider-->
<entity entity-name="OAuthServiceProviderConsumer" table-name="oauthspconsumer" package-name="">
    <field name="id" type="numeric"/>
    <field name="created" type="date-time"/>
    <field name="consumerKey" type="long-varchar"/>
    <field name="name" col-name="consumername" type="long-varchar"/>
    <field name="publicKey" type="very-long"/>
    <field name="description" type="very-long"/>
    <field name="callback" type="very-long"/>

    <prim-key field="id"/>

    <index name="oauth_sp_consumer_index" unique="true">
        <index-field name="consumerKey"/>
    </index>
</entity>

<entity entity-name="OAuthServiceProviderToken" table-name="oauthsptoken" package-name="">
    <field name="id" type="numeric"/>
    <field name="created" type="date-time"/>
    <field name="token" type="long-varchar"/>
    <field name="tokenSecret" type="long-varchar"/>
    <field name="tokenType" type="short-varchar"/>
    <field name="consumerKey" type="long-varchar"/>
    <field name="username" type="long-varchar"/>
    <field name="ttl" type="numeric"/>
    <field name="auth" col-name="spauth" type="short-varchar"/>
    <field name="callback" type="very-long"/>
    <field name="verifier" col-name="spverifier" type="long-varchar"/>
    <field name="version" col-name="spversion" type="short-varchar"/>

    <prim-key field="id"/>

    <index name="oauth_sp_token_index" unique="true">
        <index-field name="token"/>
    </index>
    <index name="oauth_sp_consumer_key_index">
        <index-field name="consumerKey"/>
    </index>
</entity>

通常、基本は仕様を模倣します。ただし、以下を処理するために導入する可能性のあるカスタム拡張機能は除きます。

  • IPアドレスの制限
  • トークンのために生きる時間
  • トークンの更新/更新を可能にする
  • リストは続きます...
于 2010-12-27T22:13:32.093 に答える