単一ページのアプリケーションへのログインページを別のページにするのはなぜですか？

28

SPAのログインページをSPAのページではない別のページにするのが一般的であるように思えるのはなぜですか？

私が考えることができるのはセキュリティだけですが、特定のセキュリティの理由を考えることはできません。ログインページがSPAの一部である場合、FirebugやWebインスペクターなどのツールで見ることができるajaxを介してユーザー名/パスワードを送信しますが、通常として送信してもPOSTリクエスト。このデータを簡単にキャプチャできる他のツール（フィドラー、httpscoopなど）があります。

何か足りないものはありますか？

javascript architecture

— ライアンゼック
ソース

2

この場合、理由があるとは思わないか、理由があるとは思わない。なぜだろうか？

— スティーブンエバーズ

1

それに対する私の議論は、アプリケーションの残りの部分がSPAアーキテクチャである一方で、ログインページを別個のhtmlページとして持つことは、実際の利益なしに奇妙に見えることです（msanfordの作った点にはメリットがありますが）。

— ライアンゼック

@ryanzecありがとう。実際のメリットがあることを示すために、例を追加しました。まず、特にログインの失敗（またはアカウントの停止など）の場合、他の場所にあるアセットの読み込みを延期することの節約は無視できません。第二に、より高度な非同期依存ベースのモジュールシステムよりも実装がはるかに高速であり、開発ライフサイクルは重要な考慮事項です（Opbeatのオフィスマントラ*（下品を含む）を参照）。

— msanford

「通常のPOSTリクエストとして送信した場合でも、このデータを簡単にキャプチャできる他のツールがあります」。あなたのログインフォームはHTTPSで保護されていますか？

— アジュレーン

@ajlaneはい、私のログイン（および実際には、アプリケーション全体）はHTTPSの背後で実行されます

— -ryanzec

18

おそらく、アプリケーションでのみ必要とされるクライアント側のアセット（重いJavaScriptフレームワーク、画像など）のロードを節約することでしょう。

同様のパフォーマンス目標を達成するためのより洗練された手段があります（「Malte Ubl＆John Hjelmstad：JavaScriptローディングへの斬新で効率的なアプローチ-JSConf EU 2012」を参照）。とにかく、Webアプリはほとんどすべてのアセットを使用します。

これは、http：//infogr.amベータのようなサイトで実際に見ることができます。

http://infogr.am/login/は jquery、 raphael、カスタムjsおよび3つのcssファイルをロードします。
http://infogr.am/beta/（アプリケーションのメインSPIページ）は、10個のjavascriptフレームワーク、5個の外部cssファイル、および約60個の画像をロードします。

— msanford
ソース

更新：2016年に、angular2フロントエンドとJBossバックエンドを使用して、同じ理由でこれを行っています。

— msanford

18

賛成または反対の合理的な議論があると思いますが、決定にもテクノロジーが役割を果たしていると思います。

別のログイン「ページ」を使用すると、「ディレクトリセキュリティ」の使用が可能になると主張できます。通常、ログイン「ページ」は誰でも見ることができますが、認証されたユーザーのみがアプリケーションの「ページ」とその「ディレクトリ」を見ることができます。ルートはロックダウンすることもできます。/Account/は/ App /とは異なり、それぞれに独自のセキュリティ「プロファイル」があります。

また、SPAアプローチを使用していて、認証とアプリケーションエクスペリエンスを混在させている場合、ロジックが複雑になる可能性があります。ユーザーが「ここにいるのでログインしている」と仮定する代わりに、認証ステータスを常に確認し、「このユーザーはここにいるべきか」と尋ねる必要があります。

また、ログインページは通常、消費者向けサイトにあります。www.yourapp.comにアクセスすると、情報、連絡先、サポートなどに関する情報が表示されます。認証では、ターゲットのホスト全体にリダイレクトできます。

別のログインページを保持し、「消費者向け」サイト用にまったく異なるアプリを実際に持っている理由は、認証されていないユーザーにはほとんど公開できないためです。偶然、ログインページでバカがバカになり始めますが、アプリ側に影響を与えたくありません..ログインが単純な認証ルックアップのみを実行している場合でも、bozoが私の影響を受けないようにするのに役立ちますユーザーエクスペリエンス..最悪の場合、私のコンシューマサイトはダウンし、誰もログインできませんが、少なくともログインしているユーザーは知らず、ユーザーエクスペリエンスは遅くなりません。それが防弾チョイスだとは言いません。認証されていないエリアへのリスクを隔離しました。

— ハンゾロ
ソース

1

多くの場合、セキュリティが大きな理由です。

— -JustinC

1

@JustinC：より安全にログインするために別のページで説明してください。

— ライアンゼック

必ずしもファイルシステム属性を介してではありません（ただし、状況によってはそれが必要な場合もあります）が、特定のリソースまたはリソースグループに適用される選択的認証/承認方法の適用によるWebアプリコンテナー/サーブレットソフトウェア/ランタイム全体として（実際には、ディレクトリ）：ログインページと特定の静的リソース（画像、スタイルシート、エラーページ）の場合、多くの場合、匿名アクセスで十分です。他のページについては、より特定の認証/許可が必要になる場合があります。

— -JustinC

2

アプリの外部で認証を行うと、アプリの懸念から認証が分離されます。実際のセキュリティは、実装と技術に依存します

— Hanzolo

更新2017：IdentityServer

— hanzolo

10

これを行う理由の1つは、通常のCookieベースのセッションを使用できるためです。ユーザーがログインすると、応答が最初のメインページとともにCookieを送信し、その後のすべてのAjax呼び出しがCookieをサーバーに送り返します。

— グランドマスターB
ソース

6

これにはいくつかの理由があります。

web.xmlで通常のパスベースのアクセス制御ルールを使用できます。
Ajaxアプリケーション全体が適切に保護されているとは確信できません。自信をつけるために広範なテストを行う必要があります。
認証をフレームワーク（Spring Securityなど）、サードパーティアプリケーション、またはSSOソリューション（CASやJOSSOなど）に委任できます。
ブラウザにユーザーのユーザー名と（オプションで）パスワードをキャッシュさせることができます。

— n0rm1e
ソース