I'm working on a 100% ExtJS application; the browser downloads all the JavaScript and a single HTML file once; everything runs in the browser after that.
When all the panels are rendered at startup (i.e., when Ext.onReady() fires) I need some panels to be hidden depending on the user's permissions. Is there a common/best practice for configuring the GUI at startup depending on user permissions?
I think one solution might be to have some panels hidden by default. An AJAX call could be made at startup to get user permissions, and then panels could be un-hidden depending on those permissions. However, I suspect there are better solutions.
Any tips would be greatly appreciated.
Note: I understand that the front-end javascript can't be trusted as the sole mechanism for security checks and that the backend application would need to verify all the actions received from the front-end.
Why not just write a server-side script that outputs privileged client-side code based on the user's authentication status? Instead of having your client-side code fetch permission data and branch on them, just have the client-side hit a script that outputs the appropriate javascript.
So if you've got a special "SuperAdminPanel" component, the only way the client ever sees the code is if they hit your authentication-aware user-js script, and are recognized as a super-admin.
In the general case, such a script could just echo out the appropriate script for the currently-authenticated user's level. It could easily be extended to pass code or configuration specific to individual users, as well.
Related
In attached image button is disabled by default based on access, however if i delete the property highlighted it gets enabled & user can able to perform actions.
Please do provide solution to restrict it.
Please see image attached related to issue with chrome Developer tool
You can't stop the user from doing that. Its their browser, and it's entirely in their control. Any user can manipulate the page in any way they choose, and run any script they choose from the console, etc etc. If the have the knowledge and inclination, they can do as they please. If they want to change the page to try and make a malicious or incorrect submission of they data, they can.
The mitigation you can (and must) put in place is to check and sanitise all data coming into your server-side API to guard against what is coming from the client being malicious or otherwise inappropriate.
Bear in mind your API just accepts HTTP requests, there's nothing to say a client even needs to use your web app to make requests, they could use a tool like PostMan or any other HTTP client to attack it. They can bypass the browser completely. So you have to apply all permissions, data checking etc on the server first to ensure security. If you then apply it on the browser-based web app, that's nice but you have to regard it as just a usability feature - it can never provide any real security.
well, as all html code in the browser you cannot prevent it from being manipulated, never trust the client and check the access of this action in the backend.
Keep in mind that even if the button is disabled, a developer can rebuild the request of this form and send it without using any user interface.
There is an alternative way that you can do in this kind of situation. You must unbind the event when the button is disabled and bind it again when the button is enabled. It will solve your problem.
Much better sanitize it in server side.
I am creating an Angular 1 SPA. Certain controls are only visible to users with certain permissions. This is based on scope variables set by server api calls.
It occurred to me that if I could access these variables through a browsers dev console, I could change their values.
I tried this for example:
angular.element($0).scope().$parent.myUserInfo.accessType = "admin"
angular.element($0).scope().$apply()
And sure enough, the admin controls popped up on the page even though I was not logged in as an admin. Is there a best practice to stop this or am I going about it completely wrong?
The authentication always have to be made on the server side.
I don't know what you are trying to do, but if the user interacts with some webService/Rest API, etc... the server should disallow such interactions.
If the accessType property of your scope is just a way for you to know which UI you should display to the user, and the authentication/session mechanism is correctly handled by the server, that should not be a problem.
However, you cannot disallow the user to play with the dev console, so you'd better handle the authentication correctly.
I am not sure if there is a way of protecting values in $scope.
But as JavaScript is executed client-side and it is therefore be possible for users to modify said code, I would always verify permissions server-side. Then it wouldn't matter if users enable the admin controls client-side as they have no permission to use the api calls.
I am new to AngularJS and trying to grasp the concept of implementing an access control layer so that some pages/menus will be hidden from certain users.
I usually implement ACL and all routes on the back-end (PHP/MySQL) but this project require me to do everything on the client side only.
We have a remote server that is in charge of authentication and upon successful login, will return an is_admin flag so that I know whether to display the additional info.
Although not likely, since Angular is also the rendering engine and is in charge of all the logic, I am afraid that users will be able to play with browser developer tools and/or other 3rd party tools and gain access to those areas (since all scripts & logic will be visible to them in the browser).
So if I do something like:
if (user.is_admin === true)
{
//display the additional admin data...
}
A user can potentially set user.is_admin = true in the browser tools and gain access.
With server side rendering such as PHP, the user will never be able to even know about these hidden areas. i.e
<?php
if ($user->is_admin === true) {...}//user will never ever see that or be able to modify $user properties
?>
Of course that the server will keep on authenticating every request so this exploit will only allow limited access, but still seems like a non secure way of hiding sections from certain users.
Am I missing something in Angular or is there a better way of doing it so that it's bullet-proof for client side hacks?
The Angular way of hiding sections is with the ng-if/ng-show/ng-hide directives, as in:
<div ng-if="is_admin">...</div>
You can't hide those divs from people who look at the source, or the resources you make available in your app. So don't provide admin data to those views.
My approach was to make an "admin" app in addition to the "standard" app and link between them. This way, the only things exposed are links to the admin site, which are blocked to non-admin users:
<div ng-if="is_admin">Link</div>
All requests to my /admin/* pages return a 401 status code if they are not an admin. The REST resources also return 401 status codes as appropriate.
(Edit: changed above ng-hide to ng-if to suppress those divs in the resulting DOM.)
I have created a web page with RoR and i am using auth system that i wrote. Now i would like to create an admin panel, where i can see the user info etc..
I am not sure but what i though is to add a column name to auth system like admin? giving a default name false. Then if the admin? is true admin panel opens instead of the web page login.
I wonder if i can use the same auth system so in order to login to page it logs in to admin panel.
But in the controller it will check if admin? is true for every user, i am not sure about the burden in terms of the system requirments as it will check every user.
And i know there are other gems for admin panel but its fine i can design it. I am just not sure which way is the efficient way.
The burden on the system will be negligible. It depends a little bit upon how your auth system is configured, but I am assuming that you give the user a token when he/she is properly logged in.
When the user first tries to sign in, you should check if they are an admin. At this point, if they are, then you can sign them in as an admin, also storing that information in the session. You should perform this check on the controller actions where they need to be an admin. It will not affect performance to any noticeable degree and is important for the security of your site.
Also, you may want to check out the CanCanCan gem, which is a fork of CanCan built by Ryan Bates, for an example of how this works. Unless you're building the application for educational purposes, I highly recommend the CanCanCan gem.
Hope this helps!
In addition to that, you may try Rails_Admin, which provides an easy-to-use interface for managing your data.
And I've considered to use this gem for my project, which is a huge database, so it seems to very helpful.
I'm looking for information on how to implement secure pages using ExtJS 4. By secure pages I mean the user will log into our website using Siteminder (SSO) and so we will have the user's identity. Then we would determine what roles the user would have by making a database/LDAP call and only render those views/components that the user has access to.
Several questions come to mind:
1.) Of course I would expect we would do the authorization check prior to rendering the pages on the server-side, so how do you do this prior to firing Ext.onReady()? I need to have the ExtJS wait for the response from the server?
2.) What is the best way to organize a page's components where the case may be someone could see a particular component and another person cannot?
3.) How do I deliver the resulting page (i.e., the pieces the user has access to) to the client?
TIA!
If you're working from a Java background and are comfortable using Spring, I wrote up an approach using Spring Security here. This will allow you to plug-in any authentication mechanism you want. The main difference is that instead of using an index.html to bootstrap the application, I have a JSP so that the Spring Servlet Filter will fire for authentication. The Ext JS app blocks until the user is authenticated and the user's roles/permissions are provided.
Use a server side technology to pre-process authorization by putting your JS App launch script into a JSP/GSP. What this does is forces server side components to kick off first and then render the HTML/JS/CSS to the client. For full RIA app use index.gsp(or jsp) and the your URL stays "domain/contextroot" .
You can interrogate access privs to content via ajax request to server or alternatively you could set JS variables via again JSP technology that is processed first before the rest of the client response is returned.
< g:javascript>
//global env var definition
var env = "${System.getProperty(Environment.KEY)}";
< /g:javascript>
Both of these are not 100% safe as client side code can be altered. The real security enforcement must be handled on server side when data is submitted for processing.
'3. Easy way would be to hide/show views etc based on 2. above. There are also some experimentation out there with modularizing the client side MVC application by lazy(manually) initializing controllers that may or may not be needed.
Hope this helps.
DB :)
I am currently experimenting with the following solution. Although it will only work for apps with a rather simple set of users, it could be of some help to you.
To begin with, user authentication is done without extjs, using a simple HTML/CSS page. Once the user logs in, its details (user id, role) are saved into the PHP session. And then the page redirects to one of two extjs apps.
One app for normal users (I'll call them clients), these are people who's client side JS does not include any admin functionality. The other app is for admins.
Both apps have their classes inherit from base classes. So we have, for example, base.mainMenu from which both admin.mainMenu and clients.mainMenu inherit. The only difference in the app.js script is the controllers loaded, and per extJS 4 dynamic loading module, only the related views are loaded (ie, seen on the client side). In my case, all pages load dynamically anyway, so my users can only dynamically load pages in their mainmenu.
The admin app blocks certain features using a global JS variable that includes the user's role. So for example, the hiding of an 'edit' button from moderators (an admin group with less rights) is done once the view is loaded (in practice this is actually done by not loading a plugin that allows editing on the view).
To wrap it all up, any call to the server checks whether the session user has rights for the requested operation, so regardless of client side scripts, server operation can only be performed by people with the appropriate rights.
To summarise, you have 3 different strategies that you can mix-and-match:
Loading different apps for different users. If your classes all inherent from base classes, this is easier than maintaining 2 or more completely different apps.
Using a global JS variable to disable/enable certain features for certain users. This is only good if you don't have a problem with the client side loading features that are then disabled (but still seen by debuggers).
Regardless of anything, all server-side calls are checked against session variable.
check out Role-based access control. I use Yii's database-based RBAC, and have a php script that returns the rbac rules in json format when ext starts up
on the client, the best bet is to simply hide or disable functionality that is not allowed.
on the server, you should throw a 403 http error if the user is not allowed to perform a function. handle ajax exceptions in ext and check for 403s.