0

MySQL データベースに保存されているデータにアクセスするために、独自のモバイル アプリ用の API を作成したいと考えています。ただし、3-legged OAuth アプローチに関する多くの記事を読みましたが、これは私が探しているソリューションではないと思います。私がそれを正しく理解している場合、たとえば、新しい Twitter クライアントを作成して Twitter Api を使用したい場合は、3 本足のアプローチがより使いやすくなります。

しかし、私のアプリはサードパーティのアプリではなく、私のアプリとウェブサイトは含まれています。データベースは私からです。したがって、ユーザーがアプリを起動してユーザーIDとパスワードを入力すると、APIにはユーザーID/パスワードが正しいかどうかをチェックし、結果として「true」をアプリに返す機能があると仮定します。アプリは、ログインが必要な機能にアクセスする可能性をユーザーに提供します。そのため、ユーザーを Web サイトにリダイレクトして、userid/pw へのアクセスを「許可」するべきではありません。

私がそれを正しく理解していれば、2本足のアプローチが私の目的に適している可能性が高くなります。しかし、私はこれにも混乱しています。ユーザーが ID と pw を入力すると、これらの資格情報が Web サービスによってデータベースで検索され、トークンがこのユーザーのデータベースで検索され、アプリに送信されると仮定します。さらに、アプリ トークンは最初からアプリに保存され、リクエストと共に送信されます。アプリはこのユーザー トークンを DB から内部的に保存し、ユーザーが Web サービスで何かを行うたびにこのトークンを使用します。Web サービスへのすべての要求で、トークンがサービスに送信され、サービスはトークンが有効なものであるかどうかをチェックします。そうでない場合、アプリにエラーが送信されます。

この例を調べました: http://code.google.com/p/oauth-php/wiki/ConsumerHowTo#Two-legged_OAuth

しかし、ユーザーのユーザーID/パスワードがデータベースで検索されることについては何も言及されていません...

これを解決する方法を誰か説明できますか?

4

1 に答える 1

0

Two-legged OAuth は Client-Server に似ています。これは、サーバーからのデータへのフル アクセスを要求するクライアント アプリです。クライアントは、どのユーザーがクライアントにアクセスしているかに関係なく、資格情報によって許可されているすべてのデータに完全にアクセスできます。

Three-legged OAuth は User-Client-Server です。サーバーからユーザーのデータへのアクセスを取得するように要求するクライアントです。クライアントは、許可されたユーザーのデータにのみアクセスできます (ユーザーがアクセスを取り消すまで)。

于 2013-03-28T20:23:45.780 に答える