8

私たちは、iPhone アプリを作成する請負業者を雇いました。私は、ServiceStack を使用してそのバックエンド サービスを作成し始めています。

私は一般的に承認に苦労しています。使用する承認の種類とその実装方法です。
ServiceStack、HTTP、および認証については (まだ) よくわかりません。これを読みましたが、おそらくまだ何か間違ったことをしている可能性があります。

既存のレガシー データベースのユーザー名とパスワードを使用して認証します (ただし、それ以外には何もありません。新しいユーザーの登録も、別のアクセス許可もありません。認証のみです)。
そのため、独自のプロバイダーを作成する必要があります。

このチュートリアルCredentialsAuthProviderの助けを借りて、なんとか実装することができました。 ブラウザでテストすると動作します：

  • サービスに電話して 401 を受け取る
  • に投稿auth/credentials
  • サービスを再度呼び出して、正しい結果を得る

しかし、Fiddler で試してみると、同じワークフローが機能しないことに気付きました。

POST がauth/credentials動作します。私はこれを投稿します：

POST http://localhost:52690/auth/credentials?format=json HTTP/1.1
User-Agent: Fiddler
Host: localhost:52690
Content-Length: 74
Content-Type: application/json; charset=utf-8

{
  "UserName": "chspe",
  "Password": "xyz",
  "RememberMe": true
}

...そしてこれを取得します：

HTTP/1.1 200 OK
Server: ASP.NET Development Server/10.0.0.0
Date: Fri, 14 Jun 2013 13:07:35 GMT
X-AspNet-Version: 4.0.30319
X-Powered-By: ServiceStack/3,949 Win32NT/.NET
Set-Cookie: ss-id=3YUUgfwIeJd7PedFK5Th; path=/; HttpOnly
Set-Cookie: ss-pid=zQJ5Z4Vq7AY+BpVwbttj; expires=Tue, 14-Jun-2033 13:07:35 GMT; path=/; HttpOnly
Set-Cookie: ss-opt=perm; expires=Tue, 14-Jun-2033 13:07:35 GMT; path=/; HttpOnly
Set-Cookie: X-UAId=; expires=Tue, 14-Jun-2033 13:07:35 GMT; path=/; HttpOnly
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Length: 75
Connection: Close

{"sessionId":"zQJ5Z4Vq7AY+BpVwbttj","userName":"chspe","responseStatus":{}}

は、私にはよく見えますよ。
しかし、実際のサービスへの呼び出しは依然として 401 を返します。

GET http://localhost:52690/hello/world?format=json HTTP/1.1
User-Agent: Fiddler
Host: localhost:52690
Content-Length: 0
Content-Type: application/json; charset=utf-8

応答：

HTTP/1.1 401 Unauthorized
Server: ASP.NET Development Server/10.0.0.0
Date: Fri, 14 Jun 2013 13:07:44 GMT
X-AspNet-Version: 4.0.30319
WWW-Authenticate: credentials realm="/auth/credentials"
X-Powered-By: ServiceStack/3,949 Win32NT/.NET
Cache-Control: private
Content-Length: 0
Connection: Close

(これはServiceStack.Host.AspNet パッケージHelloServiceからのもので、属性を追加しただけです)[Authorize]

[Authorize]属性を削除するとまったく同じ呼び出しが機能するため、実際の要求は正しいです。

CredentialsAuthProviderが Cookie で動作しているように見えることに気付きました (Set-Cookie: ...最初の応答に数行あります)。

最初の質問: CredentialsAuthProvider は、ブラウザーではないクライアントにとっても正しい選択ですか?

Fiddler は Cookie を認識しないようですが、iPhone (またはその他のモバイル デバイス)が認識できるかどうかはどうすればわかりますか?

次に、代わりに Basic 認証を使用してみました。
これが私のものBasicAuthProviderです：

public class MyBasicAuthProvider : BasicAuthProvider
{
    public override object Authenticate(IServiceBase authService, IAuthSession session, Auth request)
    {
        if (request.UserName == "MyUser")
        {
            return true;
        }
    }
}

しかし、私は困惑しています-これをブラウザから動作させることさえできません。

サービスの URL をブラウザにロードすると、ウィンドウがポップアップして、ユーザー名とパスワードを要求されます。
正しいユーザー名を入力して Enter キーを押すと、同じウィンドウがすぐに再び表示されます。(正しい) データを入力する頻度に関係なく、何度も何度も... などです。

ただし、ServiceStack が実際に my を使用していることがわかりMyBasicAuthProviderます。Visual Studio でブレークポイントを設定すると、ユーザー名が認識されて が返されることがわかるからTrueです。

2 番目の質問: 何が間違っていますか?

自分のデータベースで Basic Auth を機能させるには、さらに何かする必要がありますか? オーバーライドではAuthenticate十分ではありませんか?

4

1 に答える 1

5

私はあなたの質問の ServiceStack の終わりに答えようとしますが、HTTP 経由の認証の処理と、iPhone アプリが HTTP 要求/応答を処理する方法を調べる必要があると思います。また、これにより、 ServiceStack が認証を処理する方法についての洞察が得られると思います。

CredentialsAuthProvider は、ブラウザーではないクライアントにとっても正しい選択ですか?
Credentials または Basic を使用できると思います。独自のデータベースにユーザー名/パスワードがあるため、ある種のカスタム認証が必要です (CredentialsAuthProvider または BasicAuthProvider のいずれかをサブクラス化し、TryAuthenticate をオーバーライドできます)。この 2 つの違いは、クライアント (この場合は iPhone アプリ) がサービスへの HTTP 要求にユーザー名/パスワードを入れる場所です。Credentials では、それは体の一部です。Basic では、Authorization ヘッダーの一部です。「サーバー側」では、ServiceStack は、選択した *Provider クラス/コードに必要なことを抽象化します。

しかし、Fiddler で試してみると、同じワークフローが機能しないことに気付きました。
正しい。Fiddler はセッション Cookie を保持せず、後続の要求でそれらを送信します (つまり、ブラウザーが行うように)。Fiddler を使用する場合は、それらを「手動で」提供する必要があります。

2 番目の質問: 何が間違っていますか?
ServiceStack には、認証を要求する「ポップアップ ウィンドウ」を起動するものはないと思います。これは「統合 Windows 認証」の問題のようです。しかし、確かではありません。

于 2013-06-17T17:38:38.620 に答える