I have a Django project with various REST APIs. The permission to access those APIs are defined throught rest_framework permission classes and django.contrib.auth.models Permission model.
The documentation of those apis is automatically generated using drf_yasg library, i need to find a way to inlcude in the schema generated from drf-yasg the needed permission to access every api without the need to write id down manually. Anyone can give me an hint?
You'll need to take a look at SchemaGenerator and AutoSchema classes.
However, please be very careful when updating or manipulating these as their whole purpose is generating OpenAPI3 compliant schemas.
And whilst it might seem very helpful and useful to have some kinds of permissions inspectors, after all inspects many things, however permissions sadly isn't one of them.
I had a little Google around and I found a github post discussing this very topic, and whilst it's fairly bad practice to link to external sites, I think this can be an exceptional circumstance as the poster of the comment has articulated the answer in a way I don't understand, but does satisfy your question (maybe with some customisations).
https://github.com/axnsan12/drf-yasg/issues/358#issuecomment-545827035
Related
I'm documenting a django project that use DRF. I already generated a dynamic API schema using openapi and redoc. Very cool solutions
However, I miss the permissions part in all of this
I have a lot of permissions (permission_classes) in the viewsets and some functions. Do you know any solution to include the permission in the schema, or in a documentation in general?
Going further, how do you document permissions in a APIs in general?
I already have an idea: include the permissions in a custom description in the schema, but it's still dirty
Thanks. José.-
PS: Sorry for the poor english
DRF is in the process of deprecating the use of the coreapi package, however currently there is not easy way within that solution to get security schemas to be added to your documentation.
However there is an alternative https://drf-yasg.readthedocs.io/en/stable/ this tool claims to support extracting these values (but I personally have not used it for that yet).
It's been a while since I last used Django for a project and there have been some really great advances in the core project and the ecosystem around it.
One of those is the mature API development libraries like django-rest-framework.
So far I'm loving it. But it seems that all the guides I've found are disabling the Django Admin when using Django Rest Framework.
The reasons I've seen given were essentially "We don't need it for anything" or "We aren't using sessions, which Admin uses, so it won't work, so we're not using it."
"Don't need it" is a valid reason.
But other than that, are there reasons that it's bad practice to keep the Django Admin enabled when the project is primarily used as an API?
For my purposes, I find it convenient to manage user permissions and as a simple way to code admin only functions for dealing with the underlying data.
note: I've considered whether this question is designed to elicit opinions, which is not appropriate on SO. I believe that the answers I'm asking for will be technical or security based reasons with fact or experience based reasoning.
Totally agree.
On my current project, users are getting and setting ALL data via django-rest-framework.
Like you, I find the admin site convenient to manage user permissions, permissions groups, writing emails, sms, mobile applications push and more.
More, all these models are being translated, and translation is set in THE ADMIN SITE !!!
So, if we need a new object with translation, we do not need a new app release (example in pic of a question).
objects translations are readable and clear.
Data is organized nicely with minimal effort.
Admin get cool skins (jet / grappelli etc etc)
Language activation works like a charm in the APIViews.
I am relatively new to DRF, but found viewsets an amazing abstraction technique for writing RESTful API. I am having a hard time correlating Viewsets with REST methods though. Let's say I have a viewset for Userprofiles and somebody new creates a profile on client.
Should this send a PUT or a POST ?
Which url should this request go to, http://user or http://user/new_id ?
If I want this profile only accessible to the user or admin(all CRUD operations), then where should I handle the code for making it inaccessible to others ?
Should I create a new permission ? If yes, should I handle rest methods in has_permission/has_object_permission ?
I have gone through the tutorial, and know how permissions/mixins works, but I am not able to connect these dots here.
1/ In general, POST is for creating new, PUT is for updating. See the docs on the SimpleRouter to show how the various types of Http methods align with various actions in your Django backend.
2/ You'll find that different situations call for different routing methods. If yours is standard, you may want to use a SimpleRouter like the example above. In that case, creating a new user would be a POST request to /user/ and updating a user would be a PUT request to /user/{{user_id}}/.
3/ To limit access to various API methods, you want to use Permissions. It's possible that you could use one of DRF's Custom Permissions. I've found that in general, if you want only the user to access his/her own profile, it's easier to either use conditional logic within a view (i.e., return a DRF PermissionDenied exception in the view logic if the request.user.pk is not the pk of that REST url. More often than not, I've used the UserPassesTestMixin from Django Braces, that works pretty well to filter user permissions.
4/ I guess the Django Braces mixin above answers this question. You should include a test_func method if you're using Django Braces that returns True if you want to grant the user access, and False otherwise.
Hope this helps! I agree that these are difficult parts of DRF and perhaps some of these could more effectively get incorporated into the source. Good luck!
I'm creating a django app which needs some document management functionality - users will upload documents, they'll be viewing lists of the documents and selecting them in fairly simple ways (Primarily, they'll be shown a set of documents in specific categories shared by others in their organisation).
Because I want to integrate this with my app, I don't need a very feature rich user interface (in fact, the app or library could be entirely unusable without further coding without that being a problem). It does have to be usable with django.
So - what are some good apps or libraries for django that provide appropriate models and UI elements suitable for integration into a larger app.?
I've looked at the django packages page, and none of the items on there are, as far as I can, see especially suitable. In particular, Mayan does not appear to have been created with integration in mind.
I haven't personally used these apps, but Django Packages is always a good starting place. Have you looked at under Document Management?
Mayan (rtd, github, homepage) looks to be actively maintained and pretty mature.
The other two listed are django-treenav and django-file-picker, though they do not seem to be as robust or as actively maintained, but they may be a good fit given your basic needs.
Of course if your needs are simple it may be just as easy to implement it yourself, django model's FileField is straightforward to use and they have great documentation on how to handle file uploads from forms - https://docs.djangoproject.com/en/dev/topics/http/file-uploads/.
I haven't been using Django too long, but I'm about to start a pretty hefty-sized project. I'm always nervous using fairly new frameworks (new to me) on large projects because I've been burned before. However, I'm pretty confident in Django...this will finally be the project that makes me leap from my home-grown PHP framework to a popular Python framework. (yay!)
Anyway, my question is whether or not the built-in Django admin is robust enough to use for a fully-fledged customer-facing interface (the clients will be using it themselves, not me). I see that it's pretty customizable, but I'm wondering if extensible enough to handle various non-standard cases. I don't have any concrete examples yet since I haven't started yet.
Has anyone used the Django admin for some pretty customized interfaces that non-programmer users use? Was it worth it? Would you rather have just created a home-grown admin interface specifically for the site?
Just to clarify, the users would be completely non-techy.
If I understand it correctly, you want to use the django admin for all users, to let them update the site.
If this is true, I think you may be using it in a different way from what was its main purpose, as you can get from the Django book (emphasis is mine):
For a certain class of Web sites, an
admin interface is an essential part
of the infrastructure. This is a
Web-based interface, limited to
trusted site administrators, that
enables the adding, editing and
deletion of site content.
If your users need to update content (like, let's say, adding a new article) then it may be OK.
But if you want to use it for any site interaction, then I think the user experience will not be as good.
I think a very nice example of how the admin can be used, and when it should not be used is in ReviewBoard: there, most of user actions are handled directly by the site, and only the configuration and management are then handled using the admin.
In the end, it is a matter of usability. If you think that it is OK for your application to have a different section to manage addition to the site, then Django's admin site may be a real time saver. In all other cases, maybe it is better to invest some time more.
My company has built a CMS on top of Django that handles numerous tasks (flat pages, blogs, members-only sections, importing and parsing data from external sites like youtube and flickr, mailing lists, albums songs and lyrics for artists, etc.) and so far we're still using the built-in admin. We have several very non-technical clients using it regularly.
You can go pretty far in customizing it with the admin.py files when you really get into it. The only things we've added are tinyMCE and Filebrowser to make those aspects easier for the end users.
I will say that we are working on a gallery module that is going to need a custom admin, though. Otherwise I've been pretty happy and impressed with how flexible and powerful Django's admin can be. And it's as user-friendly as you can think to make it.
It depends. The admin will let you customize quite a bit, with different groups of users having access to different tables, and if you give them access to different admin interfaces, you can even give them different sets of columns available on the tables. However, the admin isn't really set up to let you restrict users' row level access based on their authorization level. Once you've let them into a table, they can make changes to any object available to them.
You can customize widgets however you like by subclassing widget types (though the built-in filter_horizontal and raw_id_admin are indispensable and make this task simple for certain data types!)
So I guess it depends on what you mean by customers. If you mean the people who hired you to write the website (I think I'd call them clients rather than customers), then there's a good chance the admin will suit you just fine. If you mean the end users of a website, I would stick with hand-crafted django forms.
In general I view the Django admin as an interface to performing the tedious tasks of insert delete and editing. So, I'm not afraid of customizing it to a large extent (even if this means subclassing internal Django objects and passing them back to the admin interface at runtime), but be aware it will require you to read Django source (which fortunately isn't very hard to do).
So for me, the discriminator of using it or not is "insert, delete, update" of concepts that map very well to the database tables, not amount of user technical knowledge, amount I trust the users, or project size.