人力検索はてな
モバイル版を表示しています。PC版はこちら
i-mobile

ログイン認証ありシステムをangularjsで実装する場合について、postでサーバにアイパスを送り、認証結果をjsonを返すことを考えています。
phpなどサーバーサイドですとセッションを保持しますが、angularのようなクライアントサイドの場合、どのようにして、認証済かどうか判別しますか?

●質問者: FujiiRock
●カテゴリ:ウェブ制作
○ 状態 :終了
└ 回答数 : 2/2件

▽最新の回答へ

質問者から

もしかしたら、入力されたアイパスの結果を変数で保持して、認証が必要なページではそれを見に行くのかな(・ω・`)


1 ● TransFreeBSD

すみません。
まずangular.jsはよく知りませんし、アイパスというのは心当たりすらないのですが。
認証結果として帰ってくるjsonに必要事項がすべてあるのであれば、それを変数で保持すれば事足りるのではないですか?
参考までに
http://qiita.com/ngyuki/items/ed224d6b1f65ec4e0055
AuthService作って_userに情報持たせてる感じですね。

ページ遷移をHTTPに頼っていると、HTTPがセッションレスなので、Cookieなどを使ってセッションを作って保持する必要があります。
ページ遷移をHTTPによらず行うangular.jsは元々セッションレスではないので、セッションが元々保持されて(変数の内容が維持されて)ます。
#よね?


a-kuma3さんのコメント
ログインしている状態をクライアントに持ってしまうのはまずいと思います。 ログインしている状態が真っ当なものかどうかの判定は、都度 サーバ側で行うべきです。

a-kuma3さんのコメント
「アイパス」=「アイ<span style="color=gray;">(ディー)(&)</span>パス<span style="color=gray;">(ワード)</span>」なんでしょう、きっと。 ぼくも、初めて耳にしました <tt>:-)</tt>

TransFreeBSDさんのコメント
サーバ側からデータを取ってくるなどする時はサーバ側でクッキーなりトークンなりで認証する必要ありますが、クライアント側でのページ遷移とかフォームとかの切り替えなどはサーバ側に問い合わせなくてもクライアント側で閉じて問題ないと思いますよ。 元々クライアント側に見られて問題になる情報はないはずですから。 もし、クライアント側をいじってログイン状態を詐称しても、サーバ側にあるデータを使わない限りは元々非ログイン状態で読む事が出来る情報ですし、そうでない情報はサーバ側にあって、そっちは詐称してもエラーになってアクセスできないはずなので。

a-kuma3さんのコメント
酔っぱらった状態での斜め読みでしたが、Qiita の記事ではログインフレームを通り抜けた後にユーザのインスタンスを抱えていて、それがあればログイン状態だ、と判定しているようなので。 >> そうでない情報はサーバ側にあって、そっちは詐称してもエラーになってアクセスできないはずなので。 << この辺りのことが言及されてないと思うんですけれども。

TransFreeBSDさんのコメント
確かにそうですね。 この質問は「サーバ側はサーバ側で認証してセッション維持するけど、クライアント側はどうするの?」って質問だと思いました。 ただ「サーバ側で認証した後、普通はサーバで持つセッション情報をクライアント側でどう持つの?」って質問にもよめますね。 大前提はサーバはサーバで認証状態を保持してそれに基いて情報をやり取りする。 Qiitaのはその辺まるっと書かず、クライアント側のみ、認証も認証になってないダミーで書いてます。

a-kuma3さんのコメント
>> この質問は「サーバ側はサーバ側で認証してセッション維持するけど、クライアント側はどうするの?」って質問だと思いました。 << ああ、そうか。 ぼくの頭の中では、「(URL を中抜きされたみたいなやつをガードするような)ログイン中という認証は、Angular.js だとどうやって実装するの?」というふうに質問を理解してました。 セッション情報をどう持つか、という話であれば、ステートレスな http だからこそ工夫しなくちゃいけないわけで、ステートフルにも書ける Angular.js なら気にしなくても良いよね、という感じでしょうか。

FujiiRockさんのコメント
TransFreeBSDさん、ご回答ありがとうございます。 キータのサイト良く読んでみようと思います。 また、jwt対する理解が乏しかったのですが、 以下のサイトをみて、さらに教えていただいた内容の理解が深まりました。 ありがとうございます! http://qiita.com/kaiinui/items/21ec7cc8a1130a1a103a

2 ● a-kuma3

ここ、どうでしょう。
https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/
英語ですけど、図とソースを読めば何となく分かります。

Cookie を使う方法を Traditional と言ってるのは、クロスドメインを考えてのことだと思います。
ひとつのドメイン内で完結する場合には、Cookie を使う方法でも、Token をパラメータで渡す方法も、あまり違いがないと思います。

サーバサイドでは、リクエスト(Header の Cookie もしくは、body のパラメータ)を元に認証状態をチェックして、問題があれば status = 401 を返します。
status = 401 の場合は body は空で良い。

クライアント側でどう判定するか、というのは、そのページの中央付近にコードがありますが、Interseptor で判定するのが良さげです。
同じようなことを、クライアントサイドに絞ってコードが書いてあるのが stackoverflow.com にありました。
http://stackoverflow.com/questions/13478568/angularjs-redirect-to-login-page-and-persistence-of-session-id

クライアントサイドでは、401 (認証エラー) なら、location をログインページに切り替えちゃう。
stackoverflow.com のコードでは、response ではなく responseError で判定していますが同じことです。

Interseptor を使えば、認証状態のチェックが必要ないページを除いて、全てのリクエストで状態を判定して処理ができます。
ログインページは、Angular.js の中で作っても良いですけど、別ページに遷移した方がすっきりするような気がします。


Interseptor については、こちらの方がちょっと詳しいので、余裕があったら読んでみると良いかも。
http://www.webdeveasy.com/interceptors-in-angularjs-and-useful-examples/


FujiiRockさんのコメント
ありがとうございます。 教えていただいた最初のサイトで大体の概要把握できました。 「サーバサイド」 ・/api ルートはjwt管理配下にする。 ・認証のpostリクエストがあったら、認証を行い、OKだったらjwtを発行する。 「クライアント」 ・認証OKだったら、jwtからtokenを取り出してセッションストレージに格納。 ・サーバへのリクエストは、intercepterを使い、認証状態のチェックが必要あるページは、認証判定が行われる処理を差し込めるということと理解しました。 いつもありがとうございます!

a-kuma3さんのコメント
JSON Web Token ってのがあるんですね。 寡聞にして初耳でした。 ライブラリもいっぱいあるし、有効期限も含めて検証が javascript だけでもできるっぽい。 回答者も、教えてもらってることがいっぱいあります <tt>:-)</tt>
関連質問

●質問をもっと探す●



0.人力検索はてなトップ
8.このページを友達に紹介
9.このページの先頭へ
対応機種一覧
お問い合わせ
ヘルプ/お知らせ
ログイン
無料ユーザー登録
はてなトップ