SPAのログインページがSPAの一部ではない別のページであるのがなぜ人気があるように思えるのでしょうか(ロードされ、ajaxリクエストを介してデータを送信する場合など)。
私が考えられる唯一のことはセキュリティですが、特定のセキュリティ上の理由を考えることはできません。頭に浮かぶ唯一のことは、ログインページがSPAの一部である場合、FirebugやWebインスペクターなどのツールで表示できるajaxを介してユーザー名/パスワードを送信することです。ただし、通常のPOSTリクエストとして送信した場合でも、このデータを簡単にキャプチャできる他のツール(fiddler、httpscoopなど)があります。
何か足りないものはありますか?
おそらく、アプリケーションでのみ必要なクライアント側のアセット(重いJavaScriptフレームワーク、画像、etcなど)のロードを保存することです。
同様のパフォーマンス目標を達成するためのより洗練された手段があります( " Malte Ubl&John Hjelmstad:A説的で効率的なJavaScriptロードへのアプローチ-JSConf EU 2012 "を参照)。これは実装がかなり速く、間違いなく同じくらい効率的です。特に、Webアプリがほとんどすべてのアセットを使用している場合はなおさらです。
これは http://infogr.am ベータのようなサイトで実際に見ることができます:
私は賛否両論のいくつかの合理的な議論があると思います、そして私はテクノロジーも決定に役割を果たすと思います。
別のログイン「ページ」を使用すると、「ディレクトリセキュリティ」の使用が可能になると主張できます。通常、誰でもログインの「ページ」を見ることができますが、認証されたユーザーだけがアプリケーションの「ページ」とその「ディレクトリ」を見ることができます。/Account /は/ App /とは異なり、それぞれに独自のセキュリティ「プロファイル」があるルートもロックダウンできます。
また、SPAアプローチを使用していて、認証とアプリケーションエクスペリエンスを混在させている場合、ロジックが複雑になる可能性があります。ユーザーが「ここにいるのでログインしている」と想定する代わりに、ユーザーの認証ステータスを常に確認し、「このユーザーはここにいるかどうか」を尋ねる必要があります。
また、ログインページは通常、消費者向けサイトにあります。www.yourapp.comにアクセスすると、情報、連絡先、サポートなどに関する情報と、ログインページからの「ログイン」ページが表示されます。認証、ターゲットのホスト全体にリダイレクトできます。
別のログインページを保持する理由、および実際に「消費者向け」サイト用にまったく異なるアプリを持っている理由は、認証されていないものにほとんど公開できないためです。たまたま、いくつかのmoronが私のログインページを叩き始めます、それがアプリ側に影響を与えたくありません..ログインが単純な認証ルックアップのみを行っている場合でも..ボゾの影響を受けないようにするのに役立ちますユーザーエクスペリエンス..最悪の場合、私の消費者サイトがダウンし、誰もログインできなくなりますが、少なくともログインしたユーザーは知らず、彼らのエクスペリエンスは遅くなりません..私はそれが完全な証拠だとは言っていませんが、少なくとも認証されていない領域にリスクを隔離しました。
これを行う1つの理由は、通常のCookieベースのセッションを使用できるためです。ユーザーがログインし、レスポンスが最初のメインページとともにCookieを送信します。その後、すべての後続のajax呼び出しがCookieをサーバーに送信します。
これを行う理由はいくつかあります。