36

I am wondering why it seems to be popular to have the login page of an SPA be a separate page that is not part of the SPA (as in loaded and send data through ajax requests)?

The only thing I can think of is security, but I can't think a specific security reason. I mean the only thing that comes to mind is that if your login page is part of the SPA, it sends the username/password through ajax which can be seen by such tools like firebug or web inspector; however, even if you send it as a normal POST request, there are other tools that can easily capture this data (like fiddler, httpscoop, etc.).

Is there something I am missing?

Improve this question
7
  • 2
    I don't think there is or needs to be a reason in this case. I would argue, why not?
    – Steven Evers
    Oct 25, 2012 at 19:54
  • 1
    My argument against it would be that having the login page as a separate html page while the rest of the application is a SPA architecture seems weird with no real benefit (although the point msanford made does have merit).
    – ryanzec
    Oct 25, 2012 at 20:11
  • @ryanzec Thanks. I added an example in an attempt to illustrate that there is real benefit. First, the savings of deferring asset loading elsewhere is not negligible, especially in the case of a failed login (or account suspension, etc). Second, it's much faster to implement than a more sophisticated asynchronous dependency-based module system, and development lifecycle is an important consideration (see Opbeat's office mantra* (contains vulgarity)).
    – msanford
    Oct 25, 2012 at 20:33
  • "even if you send it as a normal POST request, there are other tools that can easily capture this data". Surely your login form is protected by HTTPS?
    – ajlane
    Oct 26, 2012 at 7:55
  • @ajlane yes, my login (and actually, the entire application) is going to be running behind HTTPS
    – ryanzec
    Oct 26, 2012 at 8:58

4 Answers 4

Reset to default
19

Presumably it's to save loading a bunch of client-side assets (like heavy JavaScript frameworks, images, etc) that are only required by the application.

There are more sophisticated means of achieving a similar performance goal (see "Malte Ubl & John Hjelmstad: A novel, efficient approach to JavaScript loading -- JSConf EU 2012") but this is pretty fast to implement and arguably just as efficient, especially if your web app uses almost all of your assets anyway.

You can see this in the wild in a site like the http://infogr.am beta:

  1. http://infogr.am/login/ loads jquery, raphael, custom js and 3 css files.
  2. http://infogr.am/beta/ (the main SPI page for the application) loads 10 javascript frameworks, 5 external css files and around 60 images.
Improve this answer
1
  • Update: In 2016 with angular2 front-end and a JBoss back-end, we still do this for the same reason.
    – msanford
    Oct 26, 2016 at 14:50
19

I think there are some reasonable arguments for or against, and i'd say technology also plays a role in the decision.

One could argue having a separate login "page" enables the use of "Directory Security". Generally anyone can see the login "page", but only authenticated users can view the application "page"'s and it's "directory". Route's can also be locked down, where /Account/ is different than /App/ and each has it's own security "profile".

Also, if you're using a SPA approach and you're mixing authentication with application experience the logic could get convoluted. Instead of assuming the user is "logged in because they're here", you have to constantly check their authentication status and ask "should this user be here".

Also, the login page is generally on the consumer facing site.. you go to www.yourapp.com and it has some about info, contact, support, etc.. and a "login" page.. from the login page, after authentication, you could redirect to a whole host of targets..

The reason i keep a separate login page, and why I actually have an entirely different app for my "consumer facing" site is because i can expose very little to the unauthenticated. By chance some moron starts banging on my login page, i don’t want that to affect the app side of things.. even if the login is only doing a simple auth lookup.. it kind of helps me keep the bozo's from affecting my users experience.. Worst case, my consumer site goes down and no one can login, but at least the logged in users wont know and their experience wont start slowing.. I'm not saying that's the bullet proof choice.. but at least i've isolated the risk to the unauthenticated area..

Improve this answer
6
  • 1
    Security is often a big reason.
    – JustinC
    Oct 25, 2012 at 21:56
  • 2
    @JustinC: explain to me on a separate page for login in more secure?
    – ryanzec
    Oct 25, 2012 at 23:12
  • Not necessarily through file system attributes (but it can be if thats what the situation calls for), but the web app container/servlet software/runtime through application of selective authenticationa/authorization methods applied on either a specific resource, or to a resource group as a whole (in practical terms, a directory): for the login page and particular static resources (images, stylesheets, error pages), anonymous access is often sufficient; for other pages, a more particular authentication/authorization might be required.
    – JustinC
    Oct 25, 2012 at 23:43
  • 2
    Authenticating outside of the app isolates the authentication away from being a concern of the app. The actual security will depend on implementation and technology
    – hanzolo
    Oct 26, 2012 at 19:44
  • update 2017: IdentityServer
    – hanzolo
    Dec 6, 2017 at 0:03
10

One reason to do this is because you can then use normal cookie based sessions. User logs in, response sends cookie along with initial main page... and then all subsequent ajax calls send the cookie back to the server.

Improve this answer
1
  • You can also realize the same thing in an SPA. A login api call can set a cookie.
    – Blackclaws
    Sep 5, 2022 at 10:11
6

I see a few reasons to do this:

  1. I can use normal path-based access control rules in web.xml.
  2. I can never be sure I have protected my whole Ajax application properly, and I need to do extensive tests to be confident.
  3. I can delegate authentication to a framework (like Spring Security), a third-party application, or an SSO solution (like CAS or JOSSO).
  4. I can let the browser cache username and (optionally) passwords for the user.
Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.