Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

I only thing I can think of is security but I can't think a specific security reason. I mean the only thing that come to mind is that if your login page in 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?

share|improve this question
2  
I don't think there is or needs to be a reason in this case. I would argue, why not? –  Steve Evers Oct 25 '12 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 '12 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 '12 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 '12 at 7:55
    
@ajlane yes, my login (and actually, the entire application) is going to be running behind HTTPS –  ryanzec Oct 26 '12 at 8:58

4 Answers 4

up vote 11 down vote accepted

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.
share|improve this answer

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..

share|improve this answer
1  
Security is often a big reason. –  JustinC Oct 25 '12 at 21:56
1  
@JustinC: explain to me on a separate page for login in more secure? –  ryanzec Oct 25 '12 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 '12 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 '12 at 19:44

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.

share|improve this answer
    
+1, some things are best left simple. –  Wyatt Barnett Oct 26 '12 at 0:25

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.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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