1

This question comes from the following post:

OWIN cookie authentication get roles on client side

I've created a separate thread for the question since it is more general than one in the post above.

In short:

Let's say we have a web application with javascript as client side + ASP.NET web api as server side and also an identity server. Only authenticated users can access web api endpoints, some of them accessible only for specific roles of user.

Now the client side of application should show specific items based on what role user is in. For example: user in administrator role can see an extra tab: manage items. There are two approaches to achieve this:

  1. When rendering client side application, one could call an endpoind in web api which would return what roles user have. Based on that result, show/hide items in html.

  2. When application loads, an endpoint, which returns how the structure should look like (for example: json string) would be returned, and based on that structure client application would be rendered. No show/hide html on client side based on roles in such case.

Now regarding 1st point: some could argue that there is a security leak, since malicious user can modify html to see elements that he is not supposed to see. But in this case he will not see any content from database and will not be able to load/update it since he will not be authorized to do that based on his role which is checked in server side.

2nd point seems more valid since we keep all identity related information logic on server side. And also all unnecessary content is not in html (while in 1st point it's hidden) - so that leads to better performance? In this case though if for example developing angular application, the json structure of application should include such information as name of angular controller and route for example. Would that not add complexity to developing application?

Assume that the application itself have a lot of roles and a lot of items should be visible/not visible based on these roles.

Pros/cons between 1st and 2nd? Thanks!

Community
  • 1
  • 1
Jaunius Eitmantis
  • 211
  • 2
  • 11

1 Answers1

1

I stick always with the first suggested point.

As you mentioned the second choice will add more complexity for developing. For the 1st there is no security leak. If you don't want your users to modify the html and to access forbidden areas in your application simply use ng-if instead of ng-show. If you are not familiar - ng-if will not just hide the content with display: none;. It will completely remove it from the DOM and this leading the user unable to show that content as it is not in the DOM.

Read this for more detailed explanation for ng-if and ng-show: what is the difference between ng-if and ng-show/ng-hide

I usually have an endpoint getting information about the user - including it's role and save that user into a service (factory). This gives me the flexibility to use it everywhere in the application and check if the user has access or not to certain parts of it.

Community
  • 1
  • 1
Hristo Enev
  • 2,421
  • 18
  • 29
  • with ng-if the content is removed from DOM, there is some code in angular.js that does the removal, so I could just comment out that code and see the content:) The question is then if the removal process of these dom elements can reduce performance – Jaunius Eitmantis Jul 06 '16 at 20:41
  • 1
    I don't get your argument about the comments. Anyway .. `ng-if` is slower than `ng-show`, that's for sure. Controllers and directives have to be rerun and so on. But if you use them smart and know when to use `ng-show` and `ng-if` I don't think you will have problems with performance to hide some elements from users that do not have perimissions. Usually stuff that you will hide in this case will be links and buttons and they should not cause harm even if you hide them with `ng-show` if you have strong backend logic. – Hristo Enev Jul 06 '16 at 20:59
  • what I meant about comments is that a malicious user could still see the content of page which is removed from dom with ng-if. But that's no big harm, since backend api is still protected – Jaunius Eitmantis Aug 14 '16 at 09:06