I'm attempting to create a DRF API that can handle multi-level permissions. I have Users, Clients, and Brands. Clients can contain one or many Brands.
The way I'm trying to get User Permissions to work is a User can have access to one or many Clients. If given access to that Client they will also be given limited access to one or many Brands within that Client.
I can't wrap my head around how to manage the permissions on this. Does this need to object instance level permissions? or is there another way to organize it? I'm trying to avoid 3rd party packages, but I have seen several people mention django-guardian.
I understand this is a very general question. So I appreciate any type of response on this. Thank you.
Related
So I have a requirement where I have to maintain two types of users.
A company and all of its users, to manage day-to-day work. And also create public data like showing a few items and related images and set availability for meetings and more.
Public user who can see the items, images. and can book the meetings.
Now for the first case, every user is created by official email and password as registeruser endpoint from rest-framework. there is user profile and other company data.
For the second type of user (public), I have to give access for social login as well as login by email/mobile (maybe).
I am confused as how to configure this in the best possible way. the company datas' are important.
Should I create both user types in the same database (differentiating by user types)? or should I use a seprerate database then how to fetch data from two databases (never done this)? Also to keep my datas safe from unauthorized access.
Or is there a better way to manage all of my requirements which I'm totally unaware of? Like a better approach.
Looking for an explanation from an experienced person.
Thanks
Maybe what you want is creating a custom User model (or even keep the default one) and implement permissions on views/ressource. This can be implemented by groups, for instance, the public group, in which everyone is (can be public or even no groups) and the private group.
Once you can differentiate between your users, you can add a reference to a ressource and its subressource to the group (ForeignKey on the group) and filters necessary queryset laters on your view. On certain view, you can also restrict some endpoints, through permissions.
Another way would be to use Object Permissions.
Anyway here are the ressources :
https://www.django-rest-framework.org/api-guide/permissions/ (and django-guardian for object-level permission)
and
https://docs.djangoproject.com/en/4.0/topics/auth/default/#permissions-and-authorization
Also, you can take a look on how it is implemented on a opensource project like Sentry: https://github.com/getsentry/sentry/blob/master/src/sentry/api/endpoints/api_applications.py
I wanna build a simple ember app with sails as the backend.
There are nice blueprints that will help me with that, but I want all data to be complete user isolated. So its actually a single user application, but for multiple users.
So all data is different for each user. So when ember makes a request to /notes/findAll I only wanna return the notes corresponding to the user. On the other side a user has full rights on all data that belongs to him (except maybe the user model, which is the only special case).
What is the simplest way to do this?
I could modify the blueprints itself! But is this a good idea? It would be nice to be able to combine it later by configuration on a per-model-base.
Is there a way to do this with a policy? So a policy setting a safe user-filter?
Is there another better/default way to solve my problem?
Thanks!
I am building the same sort of application. I accomplish this by adding an owner attribute to every model, and setting it in a policy.
https://github.com/tjwebb/xtuple-api/blob/master/api/models/base/xTupleObject.js#L29-L32
I created Permission and Role models, and if the object the user is asking for relates to their User object via a Permission and Role, then they are authorized for a particular action.
https://github.com/tjwebb/xtuple-api/blob/master/api/policies/authorize.js#L51-L56
If you want to grant access to the findAll method, you might want to re-implement it in a superclass that all your controllers inherit from. I haven't gotten to this part yet, but this is my plan for solving this problem.
I'm currently working on designing a REST-style SQL-backed web application that is to support multiple types of user roles. I'm looking for ideas for implementing an authorization abstraction for it that's both simple and powerful.
The hierarchical roles in the system would be along the lines of:
superuser/admin -> group owner -> group user
A real world example of this system would be: "I'm a school administrator, I have teachers I manage, and they all have classes that contain students".
I'm thinking along the lines of a UNIX model, except one admin's data silo cannot overlap with another admin's. In the example above, one school should never have access to the data of another one.
An admin role would have full superuser powers over every group and user under him.
A group owner would only have access to the group itself and the users under it.
There can be multiple admins for one silo of data, multiple group owners per group etc.
Admins / group owners / users will generally not change what they can do, as in they abilities will pretty much fixed. The thing that will change is what pieces of data they can act upon.
I'm absolutely certain there have to be a few general patterns out there that I can start with and develop a custom authorization system around it that's fine-tuned to my system's needs. There's ACL, there are libraries along the lines of Rails' CanCan and I'm sure many more.
I'd love to know what my options are and what some of the trade-offs would be. Resources, readings, articles, books would be all great. It's likely I'll have to implement a Parse.com-like API for this web application (i.e. API clients can write custom queries as JSON maps and those will be translated to SQL on the backend) and it'll be extremely important to prevent unauthorized access in all sorts of different query variations.
Thank you.
P.S. Just to clarify, I'm not actually on Rails, the stack I'm using has no existing libraries for authorization, hence I need to roll my own.
I would check out the hartl tutorial to implement users and admins and user levels
http://ruby.railstutorial.org/chapters/modeling-users
What I am trying to do is get a list of permissions that an application will ask for when a user adds it. FQL says I need an app access token (which of course requires the application secret). I must be doing something wrong...I don't find it normal than only the developer of an application would be able to use the Graph to read the permissions the app requires. Has anyone seen something similar?
The permissions that you ask for depend on the script that is calling the login at that particular point, so it could be different in many places. One place in the app may only require basic permissions, while another place might require basic and email permissions. So you can't get a one-size-fits-all answer for an app because it isn't defined in one place, and it is not saved on the facebook server.
It might be that there is another solution to the reason why you want this information. What is it you are trying to achieve?
I have recently being trying to create a project which has several levels of user involved.
(Just an example of an abbreviated and rough schema)
ME (Super User)
Client(s)
Customer(s)
Survey Collections
SurveyUser(s)
Invitee(s)
Surveys
Invitee(s) (invitee is a child of both survey and user)
Questions
Etc
I would ideally have:
www.example.com/client/ go to a client interface which you had to be a client to access
www.example.com/customer/ go to a customer interface which you had to be a customer to access
I have already established that using a customised Django admin interface for all of them is probably not going to be possible (or is it?). I am therefore leaning towards manually creating 'admin' interfaces for each level of user, allowing them to manage their respective roles. What is the best way of having different user types and separate interfaces for each one?
I like the way of inheriting users outlined at:
http://scottbarnham.com/blog/2008/08/21/extending-the-django-user-model-with-inheritance/
But am unsure how I would set up different 'admin' areas for different users.
As a side issue that is related, I am also unsure of how to access the custom properties alongside standard user properties and how to edit/save them in the ACTUAL admin interface that I will use.
I would need to authenticate 'Client' users against a client database to check they are clients but somehow also authenticate against the user database which manages authentication, username, password etc.
I am switching from PHP to Python/Django so any advice greatly appreciated to help me along.
Thanks!
The closest I got to this was based on another stackoverflow article here: How to have 2 different admin sites in a Django project?
I ended up creating two entirely separate instances of django.contrib.admin.sites.AdminSite which seemed to work in the end, albeit not ideal.