8

I'm wondering what the best approach in AngularJS is to secure admin pages, i.e. pages that normal users shouldn't be able to see. Obviously, there will be back-end authentication but since the AngularJS app is client-side, people could still theoretically look at the routing and go to those URLs directly and look at the admin pages.

I'm using Express, PassportJS & MongoDB (Mongoose) as my backend. Naturally, they wouldn't be able to interact with the admin pages since there is server-side authentication on creation, deletion, ... but I'd much prefer to not even serve the pages to the user if they do not have the proper access. Since the app is fully client-side JS though, I'm thinking this is kind of impossible since people can just modify the routing and whatnot. What's the best way to go about this? Thanks for any input!

laggingreflex
  • 32,948
  • 35
  • 141
  • 196
thomastuts
  • 3,459
  • 3
  • 20
  • 28
  • best way would be to follow this approach http://stackoverflow.com/questions/16139660/angularjs-basic-example-to-use-authentication-in-single-page-application/16140005#16140005 – Ajay Beniwal Sep 22 '13 at 14:49
  • Do not serve the user what the user is not supposed to see: – Chris Russo Mar 25 '14 at 05:27

6 Answers6

4

I would put a check inside routeProvider. This has to be done for every route which requires authentication. You can even write a separate method and stick it to each route to avoid duplication.

$routeProvider
.when('/profile', {
  templateUrl: 'views/profile.html',
  controller: 'ProfileCtrl',
  resolve: {
    validate: function($q, $location) {
      // Either you could maintain an array of hashes on client side
      // a user do not have access to without login
      // Or hit the backend url to check it more securely
      var validateAccess = $q.defer();
      var isAllowed = ['profile', 'index', 'dashboard'].indexOf($location.hash()) !== -1;

      if (!isAllowed) {
        $location.path('/login');
      }

      validateAccess.resolve();
      return validateAccess.promise;
    }
  }
})
.otherwise({
  redirectTo: '/'
});
codef0rmer
  • 10,284
  • 9
  • 53
  • 76
2

This question is a bit old but if anyone is looking for solution out there , I was using a resource file to store my html templates and then retrieve it with webapi while validating permission and returning the html only when user authenticated.

codeman
  • 361
  • 5
  • 12
0

Why would you "much prefer" not to serve these pages to non-admin users? Do you have an actual reason to care about this, other than some instinct that you should stop people seeing things they're not "supposed" to see?

If your security is configured properly then non-admin users will not be able to access admin data or perform admin operations. That is what you should concentrate on, not inventing elaborate ways to stop them seeing admin screens that they can't use anyway. Any time you spend on this is basically time wasted, and you should spend it on more important things.

Jon Rimmer
  • 12,064
  • 2
  • 19
  • 19
  • 3
    Sorry, but I can't believe this answer, and the fact it has been voted up and elected. I work on information security and hell, the question is good, and the response is senseless. People, please, easy solution at least... htdocs and evaluate the access privileges for the resource before serving it... – Chris Russo Mar 25 '14 at 05:14
  • 1
    You claim that it is "senseless" but make no counter-argument. What's sensitive is your data, not the HTML in your admin pages. Any effort effort spent securing the latter is security theatre that does nothing, and is a waste of your time and your employer's money. – Jon Rimmer Mar 25 '14 at 10:29
  • 2
    I have employees, not employer, as I have a company. But let's get back to the point my friend. Disclosing information is a security flaw, disclosing a protected area, even the visual interface of something shouldn't be seen, is a mistake too and could lead to social engineering among other types of attacks, you shouldn't disclosure information on how an application works if the user is not supposed to see it. Reference: We work with banks and several security standards. If you're using angular on a blog, that's alright. But it's not a good practice at all. – Chris Russo Mar 25 '14 at 21:51
  • 1
    Then you are wasting your own money. Disclosing *sensitive* information is a security flaw. There should be absolutely nothing sensitive about the UI of your application, and if there is, then its a design flaw. The smaller and simpler your application's security model, the easier it is to reason about and to ensure its correctness. Everything you add has a non-zero cost in development and maintenance, and by trying to introduce a tight security model into your presentation layer, you only serve to complicate its design and risk papering over more serious flaws at the API level. – Jon Rimmer Mar 25 '14 at 23:54
  • 1
    That's alright man, I disagree, no client would ever accept an online banking application where a hacker could see the visual interface of a restricted area, it's as simple as establishing an if(user is logged in) before sending the UI. Nothing personal man, but a important customer would never accept a solution like "it's not sensitive information, it's just a few divs". That's my last word bro, I think I already made my point. For those who care if(user is logged in) -> send angular, else, 302. – Chris Russo Mar 26 '14 at 19:03
  • I guess these are the same banks who reject my passwords for being "too long"? Security practices driven by uninformed client prejudices rather than rationality are part of the reason why software security is in such a poor state, with data theft rampant. It's our responsibility as software professionals to challenge incorrect, irrational or unreasonable practices, not kowtow to them for an easier life. – Jon Rimmer Mar 26 '14 at 21:11
  • This does not help or answer the question. He's not asking us to design his UX (including what pages are visible to whom), but how to implement this feature using Anguilar. – pnschofield Jun 24 '15 at 20:31
  • No, he is, in his own words, "wondering what the best approach" is. The best approach is not to worry about securing insensitive UI assets, and concentrate on securing sensitive data. – Jon Rimmer Jun 26 '15 at 08:49
0

The way I do is, put the angularJS html in JSP page and check session. If session validates provide access. I am not sure if that is right way. Another way is, dont use JSP, but with each API hit, check session at server, else return false. One more way is on first login, get a autogenerated key, store at server and client both, check on every API hit.

sachin
  • 1
0

You could use params in ui-router https://github.com/angular-ui/ui-router/tree/master

user3323654
  • 88
  • 2
  • 14
-1

I agree with Chris Russo's concerns. This is all about security issue. If you are using angular for your front-end then you need a framework that has a strong capability in securing your application if someone trying to attack your web site/application. I will recommend spring framework (spring_security) it has proven feature securing your web application. You need to have roles assign to each user such as ROLE_USER or ROLE_ADMIN. I will not dig into detail how to do it but this will help to resolved to your concerns. :)

rico
  • 1