Skip to content

Views decorators ordering #9596

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
fdevillard opened this issue Nov 25, 2024 · 2 comments
Open

Views decorators ordering #9596

fdevillard opened this issue Nov 25, 2024 · 2 comments

Comments

@fdevillard
Copy link

The views decorators' order matters. Indeed,

    @api_view(['GET'])
    @permission_classes([IsAuthenticated])
    def my_view(request):
        pass

is different from:

    @permission_classes([IsAuthenticated])
    @api_view(['GET'])
    def my_view(request):
        pass

This is clearly stated in the documentation (https://www.django-rest-framework.org/api-guide/views/#api-policy-decorators). Nevertheless, I find it easy to miss and it may have security implication too.

Shouldn't the latter throw an exception, as it may have security implication? If not, is anyone aware of a linter to avoid such error?

If needed, I've created a repo to illustrate this: https://github.com/fdevillard/drf-decorator-ordering-demo

Thanks ! :)

@browniebroke
Copy link
Member

Thanks fo the clear description and the example reproducing the problem. The order indeed matter, and I find the documentation pretty clear on that.

I think raising an exception (e.g. ImproperlyConfigured? ) in case of misuse would be a nice improvement, that could prevent mistakes with security implications. I'm a bit worried that this goes beyond our maintenance policy, though. The exception would be raised at import time, rather than at runtime when the view serves a request.

If we do it, we should add it to all the API policy decorators.

Copy link

stale bot commented Apr 28, 2025

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the stale label Apr 28, 2025
@auvipy auvipy removed the stale label Apr 28, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants