djoser
djoser copied to clipboard
sunscrapers
Enable / disable specific endpoints
Reviewing djoser code, if I understand it correctly, the usage is "all or nothing". I mean, UserViewSet implements all "base" features and then is routed like so:
router.register("users", views.UserViewSet)
Which generates about 20 endpoints with literally every feature it has. But this is not always expected. Djoser happily exposes /auth/users/{id} and /auth/users endpoints allowing to effectively browse whole user database (usernames & emails) for everyone who cared to register. Not all developers may want such a feature in their API.
It also exposes things such activation endpoint, resend activation (even if activation is disabled), reset username and other stuff, again - not everyone may even want those endpoints surfaced.
URL routing should be more granular - that would allow to enable/disable individual endpoints. For starters, I'd like to have POST /users (so I can create a new User) but not GET /users (so I cannot just fetch all users from the database)
The feature you described is planned for a future release - you will be able to disable certain endpoints so that they'll return 404 when used.
At the moment you can use PERMISSIONS setting to disable access to certain endpoints. In your case, you're looking for user_list permission. Please note that using permissions you can have the granularity you desire. You can also take a look at HIDE_USERS setting to disable user list.
The feature you described is planned for a future release - you will be able to disable certain endpoints so that they'll return 404 when used.
At the moment you can use
PERMISSIONSsetting to disable access to certain endpoints. In your case, you're looking foruser_listpermission. Please note that using permissions you can have the granularity you desire. You can also take a look atHIDE_USERSsetting to disable user list.
Permissions not disable endpoint. It will be in routing table anyway, and will be subject to bots/robots/attack queries.
Also it will be in automatically generated documentation if something like drf spectacular is used.
@PawelRoman @BasemHamad
This issue seems outdated a little bit, but not fixed. maybe because there are several approaches to such problems. But let's assume that our project's security requirement is not to register anyting, that have no access. So raising access to admins only or DenyAll is not an option for us.
Basically this issue is very good point to investigate architecture of djoser, and do some updates.
For actual code update require less than 20 lines, authors just need to separate UserViewSet to two classes, like it done in many django places. BaseUserViewSetMixin, that do all logic, but not nested from anywhere. In this case project users, who require granual or part endpoints management can nest from required rest_framework mixins and BaseUserViewSetMixin to provide expected results. And second class UserViewSet, that implement current nesting from ModelViewSet and BaseUserViewSetMixin, as well as actions registration.
In this case advanced users will be able to make custom solutions on same code from BaseUserViewSetMixin, and regular users will have current behaviour from UserViewSet.
NOT TESTED: Here is quick gist with example of changes in this repo, that will allow to solve such problems: https://gist.github.com/insspb/e276fb7bb9659a274942153a7f1f3596
This issue seems outdated a little bit, but not fixed. maybe because there are several approaches to such problems. But let's assume that our project's security requirement is not to register anyting, that have no access. So raising access to admins only or DenyAll is not an option for us.
I wasn't here when UserViewSet was created. It does a lot, but it kinda makes sense. I agree with you that there are a few possible approaches to this problem. I will try to look into them soon.
In the meantime, please vote in this poll https://github.com/sunscrapers/djoser/discussions/777 (related)
