I would like to add functionalities depending on whether or not the user logged in is the administrator but I don't really know which condition (for conditional rendering with delete buttons etc) I should use to check if the user is the admin or not. Is it safe to do it based on the id of the user ? In the first place, I thought about testing the user in every component I want him to have functionalities, with a state called "user" using recoiljs to get access to the user in the whole app but I'm afraid people could change the state with the react tool extension and then pretend they are the admin and so delete articles and stuff... What's the best way to test if a user is the admin or not using firebase authentification in a react project ?
It's never safe for client code to assume admin responsibilities without absolute enforcement from your backend. It's unsafe because client code can be compromised and might not work the way you expect. And it's running on a device that the user controls fully.
Client code can check some indicator to see if the user is admin (in whatever way you find suitable), but the final check needs to happen on your backend, either through security rules (if you're using Firebase products like Realtime Database, Firestore, or Cloud Storage), or in code running on a secure backend, including products like Cloud Functions.
Related
Recently started working with React / Apollo Client / Auth0 / Hasura and have some questions on handling frontend permissions. I'm using Auth0 to handle my authorization on whether a user is logged in and have my backend setup to check as well when handling mutations / queries. My question is now how to handle it on the front end.
A user can create a team that will store the info in my "teams" table and also create a record in my "team_staff" table as either a manager or coach. That was all straight forward. What I'm looking to do now is when a user visits, for example: www.mysite.com/team/update/1 to check if the user exists in the "team_staff" table and if not show them an error message or even a redirect. Also looking to hide certain buttons when viewing a team based on whether they are a staff member or not.
Should I handle this at the login and do a query for all the teams that user is a staff member on and store in a session / cookie or have a query / check inside that component each time it's called? Or am I way off and should do it another way?
Hopefully this question makes sense. Thanks!
This question makes sense, I believe many developers would have some similar problems.
TLDR;
Make API request in componentDidMount to get the right permissions (after signed in of course).
For this question, we have many solutions, and which is the best, depends on your infrastructure, your team and so on. Basically you need to call API to check the permission because your permission stored in the backend. Never store permission on the frontend storage like session, cookie, etc.
I can give some approaches.
First, call API right after signed in to get permission information, for example:
Get list of permitted routes, then, whenever user browse to a specific route, check to make sure that route in list of permitted routes.
Get list of permitted team like array of team ids, then in each route, get team id, check if that that team exist in above list.
But I'm sure you will realize they're almost the same, just different the data you get and how to process them. And two solutions totally depends on you.
All API request should be placed in componentDidMount of page component, because you will want to make sure the permission should be applied correctly as soon as the backend has changes.
Happy coding!
I am working on a web app that follows dual user-role type: Admin and Investors. I need to disable two users (be it admin type or investor type) to log in simultaneously on a website, which is opened within the same browser but different tabs.
Irrespective of their role type, at a time, either user A(admin) or user B (Investor) can log in. I am using localStorage for this purpose, storing two different key names for admin and investor.
I am new to handling sessions this way. Also, my code is quite big and nested, so I am unable to paste the snippet out of it here.
Any help even regarding how I can follow this approach, will be appreciable.
There are different approaches for handling sessions in client side of your web app, such as cookies and local storage.
In your case I think you should store your app user type and session ID in local storage like this:
s_id: admin_54759eb3c090d83494e2d80494e2d80
So before login app will check for s_id availability in local storage or not. Then in your app login flow you can decide to logout previous user and replace new session ID or just prevent from new login.
But I'd rather to use cookies. One benefit could be setting expiration time for session. For more info check out here.
I'm building an admin page for an application and have a state value 'authenticated' that flips from 'false' to 'true' after a successful login (which is authenticated on the server) which then shows the actual admin panel.
Are component state values safe from tampering by the client? Basically, if the client can modify my 'authenticated' state value to 'true', they can skip the login and go straight to the admin panel (which I obviously don't want).
I read that React Dev Tools allows the client to modify values yet everyone says "validate on the server" but I am validating on the server and updating my state accordingly, if the user is approved. If it is not wise to have a state value manage this, what is the right way to conditionally show the admin page after a successful, server-side authenticated login?
I think this is an important question since tampering with state values in a React app can have huge negative consequences on data integrity within an app/database.
TL;DR: Either require an authentication token with every request or require authentication through a session.
Never trust users always. One potentially big issue is if you "hide" admin actions behind the admins page without requiring authentication.
For example, assume the backend server uses a REST API to accept commands. In the admin panel you get links to administrative actions like a button 'Delete Everything' that sends a DELETE request to server.net:8080/api/admin/everything without requiring any authentication. If you're a user, you can find that in the code potentially and then send a DELETE request to that address from anywhere without any repercussions.
We'd never give administrative privileges to anyone who would want to delete everything... Because we'll never untrust someone. Right?
Worse, someone might find the server and fuzz some inputs to it, and oops! They manage to delete everything (or even worse, GET everything stored in the database). This wouldn't be hard to do, especially if the server you use to authenticate is the same server you use to issue commands. History has proven "security through obscurity" to be a very bad paradigm. Every action should be authenticated, even if it seems like the actions will be hard to find.
Generally, providing a JSON web token or some other form of authentication token and having the user send that with every request is a good start at least, especially if it has an expiration date. The token would be provided through a separate request with valid credentials.
Sending a token with every single request obviously isn't ideal. There are a couple of other things to try. For servers using PHP, you can probably trust sessions (though very many people who know more than me would probably disagree). In more modern cases, you could try to use Web Sockets, requiring the token after connection. Then only after authentication with the token do you allow the user to make administrative requests.
That way, even if a user knows the exact command they can send to perform any action, the server won't let them without a current session or token. Unfortunately, unless you're already using Web Sockets or depending on a session, it will likely require a lot of changes. I'd consider this to be critical though.
It is always possible to tamper values in the front-end, there is no way you can rely solely on the front end to ensure security.
Your best approach is to implement some form of authentication and authorization on your backend. In this way, even is some users pretend to be admin, they will be blocked when you do the next request to the server.
Perhaps if you can send more information regarding your problem, we can think of a more specific solution.
In a regular web app, when someone logs into the system they simply save an encrypted cookie that gets send on each request and the backend decrypts the cookie and uses the e.g. user_id/guid to lookup the user.
How do things differ when authenticating with a angular app?
Is there anything else to consider or it is basically the same process?
We use more or less the same mechanism.
Access to the application as a whole requires authentication - that is unless you're logged in, you don't get any of the javascript experience at all. This could make the login / login failure much less wizzy for the user, but in our authentication provider it's fine.
Part of our auth mechanism means the list of roles that the user has is a data object available within the browser. The javascript code uses this to decide which buttons / menus etc. are displayed. I checked with our security guy and he said something like "Well, it's a kind of direct object reference issue, but as long as each action is authorised properly, you're probably ok." So it's possible that a user could hack data values and change what they can see, but because of the next bit, they can't break our data (or see stuff that they shouldn't).
Each service call our javascript makes is authenticated and authorised. That is, the javascript call will fail if the auth token is missing or bad, but also, we internally match the auth token with a user and a set of permissions, and only execute that if the user is authorised to do so. (Note that this is good practice whether you're using Angular or not). Also note that this applies to GETs as well as POSTs - we don't want to give them data they should not see.
It gets much trickier if your API is hosted separately from your Angular site.
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.