I'm building a React application, which will end up very big. E-commerce, different users, different permissions, advertisements, lots of sensitive data flowing around, etc.
I plan on using the context Provider to help with my state management. One such facet I'm looking into is User Permissions in general. Examples being, Admin Users has the ability to alter the permissions of a regular user, Admin Users have access to an Admin Dashboard, Admin Users have the ability to refund sales and create products, etc.
Is there a best way to use Context Provider to set up these permissions? What worries me is that through most set-ups, most users with React Dev Tools will be able to open them and alter the state within to achieve whichever permissions they like. Is this unavoidable?
Related
I'm new using Snowflake and I wanted to know if it was possible to create custom roles / users for only viewing and using snowflake dashboards, so no access to the databases, tables and other features.
Some context, I'm building a dashboard showing some logs, stats and metrics regarding running applications I have a role allowing to use all features of snowflake and want to create roles / users to only access the dashboard and it's features.
So I wanted to know if there is already some predefinid roles or privileges for that otherwise the best practices for it.
Thanks
I had an answer on the snowflake community : https://community.snowflake.com/s/question/0D5Do00000CF3gJKAT/create-custom-roles-privileges-for-the-use-of-dashboards
So I created a role in Snowflake:
DashboardAdmin (granted select on the concerned objects)
DashboardAdmin is used to create and share (using the sharing dashboard feature "view only") to other users with the role and can view the dashboard without being able to edit it and the requests.
And only the owner of the dashboard can edit it
Let's say we have a web app that lets the user create "widgets". We have a new client that would like to control access to each widget with their organization's Active Directory, such that some of their users can view certain widgets and other users can edit other widgets.
What's the proper way to implement this? Should every widget have its own read group and modify group, and we let the client control the membership to these groups? Is there a better way?
Design discussions can be long-lasting and people nowadays prefer Agile methodology to keep making changes as per the new requirements to get the end refined product.
But, here is a one way in which you can implement this -
You will have one B2C(for new users) Login and one AD login(for organization users).
Then, you will have to use RBAC to have different views and features for different types of users(one B2C, 2 different users from AD) using claims and user properties for AD users. For eg, Airbnb has same website but different experiences for hosts and Users who book stays.
I am trying to create a React app where a user with "admin" role can create a new user in firebase.
The workflow would look like that:
normal login -> check userRole -> if admin: show createUserForm.
As far as I have read from the documentation, I would need an Admin SDK, but the problem is - how to implement it on client-side app? Has anyone gone through this process?
The Firebase Admin SDK should only be used in a trusted environment, i.e. a server you control or Cloud Functions. It should not (and cannot) be used in a client-side React app.
If you want to allow certain users of your React app to create accounts for other users, you'll want to move that part of the flow to a trusted environment where you can use the Admin SDK.
So the flow becomes:
Detect in the client-code whether the user is an admin (likely using a custom claim) and only show the form if they are.
Call a Cloud Function from your client with the input from the form.
Ensure the user calling Cloud Functions is authorized.
Create the user account in the Cloud Function using the Admin SDK.
As you can see this is quite involved. I highly recommend considering alternative use-cases, such as what it actually is that you want the admin to control. Once you enable a provider in Firebase Authentication, any user can create an account with that provider. Trying to control that from within your application code is just a recipe for problems. Often what you're actually trying to control is what a specific user account can do: e.g. only approved users can access certain data. Depending on where you store this data, that is much easier to control. For example: if you store the data in the Firebase Database, is is common to create a whitelist of approved users in such a case (or the inverse: a blacklist of banned users).
For different roles with there permissions example admin , moderator , user
All these roles have different permissions for accessing pages and functionalities
How can I implement this in frontend
I am using react redux as my front end
Access and Identity management are typically not features which are solely handled at the front-end.
Your user should authenticate itself against a back-end which then grants a role to your user (which you can then use to show features which are only applicable to this role). However to avoid users from using features they have no rights to, you should validate on the back-end every request they do.
This gives you the flexibility to change a user's role on the fly and invalidate their access to the application when necessary.
I have a SalesForce.com account that I use for demos. In many cases, I need the users (anyone on the web) to be able to browse the tables without making any changes.
Is there a way to make the tables public or create a guest account?
You can add a new user and create a special permission set to only allow read access. Dev orgs come with two users, but you can deactivate/re-activate users to get around the limit. Or ask SFDC support to add a few more users to your dev org.
There are several places User log-in time and date are logged so you can track them.