BrowsableAPI doesn't render for user with no permission with Django

[rvanlaar]

What happens: The BrowsableAPI throws "'WSGIRequest' object has no attribute 'successful_authenticator'"
What I expect: The BrowsableAPI shows the list view without a post form.

The BrowsableAPI doesn't render for an authenticated user with no permissions on a viewset with: DangoModelPermissions.

The permissions of a user are checked twice, once with a request.method = GET and once with a request.method = POST. During the request.method = POST the permissions need to {app}.{add_object}, which the user doesn't have.

[rvanlaar]

Also: when an unauthorized user without any permissions does a POST to a viewset which is protected with DjangoModelPermissions, the error: "'WSGIRequest' object has no attribute 'successful_authenticator'" is thrown.

What I expect: A 403 Forbidden response.

[tomchristie]

I couldn't get this to replicate.
What I did was:

• Set up a project as described in the quickstart.
• Added permissions_classes = [DjangoModelPermissions] to the UserViewSet.
• Created a regular user.
• Logged in as that user and navigated to the /users/ endpoint.

Result - displayed the browsable API with a 403.

May be able to reopen and look at this further but would require some replicable instructions, or an example test with failing pull request.

This line:

"'WSGIRequest' object has no attribute 'successful_authenticator'"

Looks to me like it's the same as #2108

Perhaps you have a custom permission that's causing an attribute error or similar.

Worth double checking which auth and permission classes you have installed and try to narrow down any configuration issues there.

[tomchristie]

One possibility would be to take this empty project: https://github.com/tomchristie/basic-rest-framework and see what steps you need to make against it in order to replicate - I'd then be able to follow the same steps.

[rvanlaar]

Thank you.

I had an error in my AuthenticationClass.

The reason I have an AuthenticationClass is that the original AuthenticationClass in DRF does an explicit enforce_csrf. This breaks havoc with HTTPS where the referer header is not the same as the serving host for DRF.

See also this issue: adamchainz/django-cors-headers#55