2016-10-29 17 views
0

私はSpring RESTバックエンドと角度フロントエンドを持っています。クライアント側のREST認証後にユーザー情報を取得する方法は?

認証は、要求JSON本体内のユーザー名とパスワードを使用してURLを「/ login」するPOST要求を使用して実行されます(私はフォームベースの認証を使用します)。 RESTバックエンドがOKコードで応答します。すべてが問題なく、フロントエンドから認証が必要な他のリクエストを実行できます。

しかし、フロントエンドは、認証されたユーザーの役割が何であるかを知っている必要があり、そのために適切なビュー/ロットを表示できる必要があります。フロントエンドでこの役割をどこから得ることができますか?私たちが認証から得た唯一の応答はOKでしたが、これはRESTにとっては問題ありません。

「/ users/[user_id]」にGETリクエストを行うことで、ユーザー情報を取得できます。しかし、私たちはユーザーIDを持っていません。ユーザー名だけです。

質問: - フロントエンドからユーザー名だけを持つRESTがロール(または他のユーザー情報)を取得する正しい方法は何ですか?

回避策として、IDの代わりにユーザー名を使用するバックエンドで新しい要求を作成することも、認証応答にユーザーIDを追加することもできます。しかし、それがRESTの観点から正しい方法であるかどうかは分かりません。

+0

バックエンドで現在のユーザー情報を取得するためにユーザーIDを渡す必要があるが、ユーザーIDを取得できない場合、バックエンドには深刻な設計上の問題があります。認証が必要なリクエストを送信できるようです。これは、バックエンドがあなたの人物を識別できることを意味します(おそらくクッキーのおかげで)。そうであれば、クッキーに暗黙的に渡されるので、パラメータとして何も渡す必要はありません。/current-userリソースだけを持つことができます。 –

+0

バックエンドとフロントエンドの両方が開発中です。バックエンドがRESTに続いてユーザー情報を提供する正しい方法は何ですか? –

+0

私はちょうどあなたに言った。バックエンドが暗黙的に(例えばクッキーを使って)リクエストを識別する方法を持っていると仮定すると、/ current-user、または/ meまたはそれに名前を付ける任意のリソースを提供することができます。たとえば、https://developer.github.com/v3/users/#get-the-authenticated-userを参照してください。 –

答えて

0

コメントで@JBNizetの問題を議論した後、RESTエンドポイントを "/ users /:user_id"から "/ users /:user_name"に変更することにしました。

0

HTTPメソッドをオーバーライドすることはできません。異なるパスの異なるクエリパラメータを使用してGET呼び出しを作成する場合は、許可されません.2つのGETパスを記述する必要があります。

GET /ユーザー/ユーザーID/{ID} GET /ユーザー/ユーザー名/ {名前}

そして、2番目の呼び出しでは、あなたは二番目の役割を取得するために所望のロジックを追加することができます。

+0

しかし、RESTの観点からは、これが正しいことがわかりません。 "DELETE/users/username"とはどういう意味ですか? –

+0

DELETEを許可しない場合は、DELETE呼び出しの実装を記述しないでください。これはREST標準に従って完全に受け入れられます。 – Sakalya

0

これには2通りの方法があります。

1)サーバからの認証が成功した後、あなたが取得し、$rootScope .This情報につながる店が出て利用できるようになり、サーバーのロジックから詳細を取得することができ、そこからユーザ名でサーバに1つの以上$http呼び出しを行いますアプリ。

2)ユーザーを認証するときに、ユーザーが有効な場合は、ユーザーの詳細を取得し、オブジェクトに格納します。

は今サーバーロジックにあなたのような
response.setHeaders("User",userDetilsObj); 

以下NOTEを行うことができます応答を戻しながら:応答は、HttpServletResponseオブジェクトです。

あなたは私たちは、これがどのようににあなたにいくつかの光を与えるコード

if(response.status == '200/OK'){ 
    $rootScope.user = response.getHeaders().User;//In this object all the user details set at server side are available now.. 
} 

希望の下に続くJS側でユーザの詳細にアクセスするには200である状態OK応答を取得すると発表したよう要求が完了した後あなたの望む結果を達成してください。

+0

ありがとうございます。これらの2つの方法は、私がこの質問で言及した回避策と非常によく似ています。問題は別のことです。 JB Nizet氏は、 "/ users /:id"を "/ users /:name"エンドポイントに置き換えることは設計上の観点からは問題ないと指摘しています。 –

+0

はい、同意しましたが、どの方が良い方法であるかを尋ねてきましたので、私はクリーナーでメンテナンス可能な最初の方法をお勧めします。 –

+0

"/ users /:name"を使うのは、IDが永遠に残る何かであるため、よりクリーンなアプローチではありません。一定の名前を変更することも、大文字と小文字を区別することもできます。どちらがログインしたかはどのように決定しますか? –

0

ユーザーを認証した時点でサーバーからユーザー情報を取得します。成功したユーザー認証にユーザーの詳細を渡します。

関連する問題