8

モバイル アプリと ServiceStack Web サービス バックエンドを構築しています。ServiceStack の認証機能は素晴らしいように見えますが、その柔軟性が失われやすいため、ガイダンスは非常に高く評価されています。Web サービス内でユーザーなどを格納するために、独自の db テーブルを使用します。登録プロセスとその後の認証を次のようにしたいと思います。

  • ユーザーは最初に電子メール アドレスのみを提供し、Web サービスは登録キーをユーザーに電子メールで送信します。
  • ユーザーがキーを入力します。アプリは、登録のために Web サービスに送信します: 電子メール、キー、および一意のデバイス識別子。
  • Web サービスはキーを検証し、電子メールとデバイス ID を保存します。アプリが後の認証に使用する認証トークンで応答します。

その後の Web サービス要求は、デバイス ID と認証トークン (またはそれを使用して作成されたハッシュ) を提供します。アプリはあまりおしゃべりではないので、Web リクエストごとに認証の詳細を送信したくなります。

質問 1 : ServiceStack の登録 API にフックする必要がありますか、それともカスタム Web サービス呼び出しをいくつか追加するだけですか? たとえば、ServiceStack の登録を使用しないと、次のようになります。

  • 電子メール アドレスとデバイス ID を使用して、登録 Web サービスに投稿します。私の Web サービスは、キーを含む登録メールを送信し、user db テーブルにレコードを追加します。
  • ユーザーがキーを入力すると、今度はキーも一緒に登録 Web サービスに再度送信されます。私のWebサービスはキーを検証し、ユーザーを登録済みとしてマークするユーザーテーブルを更新し、認証トークンを作成して記録し、呼び出し元に返します
  • 後続のリクエストは、デバイス ID をユーザー名、認証トークンをパスワードとして、http 基本認証を使用して送信されます。このサービスはあまりおしゃべりではないので、リクエストごとにクレジットが送信されます。
  • httpRequest.GetBasicAuthUserAndPassword() で資格情報を取得し、db データに対して資格情報を検証する CredentialsAuthProvider を実装します。

しかし、ServiceStack に組み込まれている登録を使用する必要があるように感じます。

質問 2 : 各リクエストで認証の詳細を渡すことの何が問題になっていますか? これにより、アプリのリクエストを簡単に作成できるようになりますが、ServiceStack の例に基づいて「完了」しているようには見えません。おそらく、すべての呼び出しを再認証する必要がある多くの要求がある場合、非効率的であるためです-他の理由はありますか? 私のアプリはせいぜい数分ごとに 1 つの Web リクエストしか行わないので、セッションを避けて各リクエストを再認証する方が簡単に思えます。

質問 3 : CredentialsAuthProvider のサブクラス化は正しい軌道に乗っていますか?

質問 4 : 認証トークンを毎回送信する代わりに、認証トークンを使用してハッシュを生成する意味はありますか? すべての通信は https 経由で行われます。

4

1 に答える 1

2

回答1: 大丈夫です。要件に従って複数の電話をかける場合。通常、認証は Cookie に基づいて機能しますが、クライアントやサーバーに保存して、ユーザーと照合できるようになりました。ここでも、デバイスを使用している場合は、ユーザーの代わりにデバイスを使用して、ユーザーをマップおよび認証できます。あなたの条件に基づいて。

代わりに手動で行う必要がある多くの詳細が隠されているため、プロバイダーを使用することをお勧めします。あなたは正しい軌道に乗っています。認証に特化したブログや、サービス スタックを使用したカスタム認証の作成方法に関するブログが多数あります。もしよろしければ、私がブックマークしたブックマークがあることをお知らせください。最新のものを検索する最良の方法は、Servicestack の twitter アカウントをチェックアウトすることです。

回答 2:これも要件どおりです。ユーザーがWIFIゾーンのみにいる場合。(ビジネス ユーザーにほとんど当てはまります)、通話に制限はありません。API 呼び出しを行い、バックグラウンドで認証を行うだけです。単純な JSON トークンは問題ありません。数バイトのみです。ただし、良好なインターネット接続を使用していない大規模なユーザー ベースが存在する場合は、認証の詳細をデバイスに保存し、それを確認することをお勧めします。ネットワーク通話を保存するためだけに。いずれにせよ、ネットワーク呼び出しはリソースを大量に消費します。

回答 3:はい、あなたは正しい道を進んでいます。詳細については、引き続きブログ エントリをご覧ください。コード スニペットと前回の更新での動作を覚えていないため、ここにコードを掲載していません。

回答4:これは少し複雑な回答です。https 経由でデータを渡すことと、ID 詐欺からユーザーを救うことは、ほとんど別のことです。現在、認証トークン (ハッシュベースの値) を生成していない場合は、http または https 経由でもユーザーを渡すことができます。これで、別のユーザーが最初のユーザーをモックしてデータを送信するために使用できます。データも https 経由で渡されますが、それでもデータは嘲笑されています。この状況を回避するために、ハッシュベースの値が使用されます。また、認証トークンを使用してカバーできるビジネス ユース ケースが他にもいくつかあります。

私があなたの質問を正しく理解し、それらに答えたかどうか教えてください?? またはさらに詳細が必要な場合は??

于 2013-07-19T16:23:49.987 に答える