2

http://www.c99.org/2010/01/23/writing-an-android-sync-provider-part-1のチュートリアルやSampleSyncAdapterサンプルなど、同期アダプターに関する多くのチュートリアルを読みました。 AndroidDeveloperWebサイトのコード。しかし、サーバー側が認証と同期のクエリをどのように処理するかを理解していません。phpを使用してmySQLサーバーデータベースからクエリを実行することはできますか？

4

1 に答える 1

15

不足している部分は、同期アダプターの一部ではありません。それはAbstractAccountAuthenticatorです。これは、ユーザーのパスワードを実際に処理してサーバーに渡すクラスであり、問​​題のサーバーと適切にペアリングされた方法で作成する必要があります。

どのように：

まず、プロセスはどのように機能しますか？

  1. ユーザーは、[設定]->[アカウントと同期]ページでユーザー名とパスワードを入力します。
  2. （後で...）同期プロセスが開始されます。
  3. SyncAdapterはblockingGetAuthToken（）を呼び出します
  4. AccountAuthenticatorが起動します。
  5. AccountAuthenticatorは、通常のhttp（または理想的にはhttps）認証を使用してサーバーに接続し、認証されると、サーバーに「トークン」を要求します。このトークンは大きな（たとえば128ビット）乱数であり、パスワードベースの認証を使用してログインした場合にのみサーバーから取得できるはずです。
  6. AccountAutenticatorはトークンをキャッシュしてから、トークンをSyncAdapterに返します。
  7. SyncAdapterはサーバー上のコンテンツにアクセスしようとし、リクエストのhttpヘッダーの一部としてトークンを渡します。
  8. サーバーは通常のhttp-authの代わりにトークンを受け入れ、リクエストの処理を許可します。
  9. 将来の同期の試行は、このプロセスの多くをスキップすることになります。次の同期試行では、SyncAdapterがblockingGetAuthToken（）を呼び出すと、AccountAuthenticatorはキャッシュされたトークンを返すだけで、再認証する必要はありません。

したがって、このトークンの使用は制限されています-しばらくすると、サーバーはそれを受け入れることを拒否します。その時点で、SyncAdapterはトークンを使用しようとし、認証エラーを受け取ります。では、何ですか？

  1. SyncAdapterはinvalidateToken（token）を呼び出し、（現在期限切れのトークン）をAccountAuthenticatorに返します。
  2. AccountAuthenticatorは、キャッシュ内のトークンを見つけて破棄します。
  3. 次のblockingGetAuthToken（）の呼び出しで、AccountAuthenticatorはサーバーと通信し、新しいトークンを取得します。そこから、同期は正常に進行します。

なんで？

したがって、いくつかの利点があります。

  1. 通常のhttpauthは、パスワードをプレーンテキストでインターネット経由で送信します。トークンが使用されている場合、パスワードは1回だけ送信され、トークンは何度も送信されます。これにより、パスワードのスニッフィングへの露出がいくらか減少します。
  2. https認証はプレーンテキストの問題を回避しますが、モバイル接続の観点からはコストがかかる可能性があります。トークンを使用すると、実際にデータを伝送するサーバー呼び出しで軽量のhttp接続が可能になります。httpsオーバーヘッドは、トークンが取得された最初のリクエストでのみ表示されます。
  3. 分離-AccountAuthenticatorは、ユーザーの実際のパスワードを知っています。SyncAdapterはトークンへのアクセスのみを取得し、パスワードを学習することはありません。これは、Googleにとって重要です。これにより、サードパーティのアプリがGmailアカウントとパスワードを使用して認証を行うことができ、サードパーティのアプリ（悪意のある可能性があります）がパスワードを取得する（そしてそれを悪意のあるnaer-doに転送する）ことができます。 -良い）

有効期限：

トークンは一種の危険です。トークンにアクセスできる人は誰でもあなたとしてログインできます。したがって、ここでのグッドプラクティス：

  1. サーバーは、一定期間後にユーザーのトークンを期限切れにする必要があります。より多くのパラノイア-より短いタイムアウト。
  2. サーバーは、ユーザーがパスワードを変更するたびに、すべてのユーザーのトークンを期限切れにする必要があります。
  3. Webインターフェイスのユーザーがログアウトした場合、サーバーはWebデバイスに割り当てられたトークンを期限切れにしないはずです。トークンの「ログアウト」の概念は実際にはありません。
  4. サーバーは、最初にトークンを要求したIPアドレスにトークンを関連付けることを検討する必要があります。その後、別のIPアドレスがそのトークンを使用しようとした場合、トークンの認証を拒否します（ただし、必ずしも期限切れになるとは限りません）。これを行う場合、サーバーはユーザーごとに複数のトークンを作成できる必要があります（ユーザーごとに1つのトークン：IPアドレスの組み合わせ）-2つのモバイルデバイスを持つユーザーを検討してください-それがないと、1つが同期するたびに無効になります他のトークン。また、両方とも自宅のWi-Fiにある2つのデバイス（ルーターの背後で1つのIPアドレスを共有し、1つのデバイスがモバイルネットワークを離れて使用を開始する）を検討してください。そのため、期限切れにしないことを選択して、自宅にいるデバイスが引き続き使用できるようにすることができます。トークン。ただし、ローミングする1つのデバイスは認証の失敗を確認し、独自の新しいトークンを確立します。
  5. パラノイアレベルに応じて、とにかくhttps経由でのみ認証トークンを受け入れることを検討してください。Firesheepは、盗まれたAuthTokenがあなたに何をもたらすことができるかを示す良い例です。ユーザーの機密データがある場合は、https経由でのみ受け入れる必要があります。また、ユーザーに機密性の高いデータがない場合でも、httpの読み取りを許可しながらhttpsでDBを変更するように要求するプロトコルを作成することを検討してください。
于 2012-01-01T02:34:30.430 に答える