Mixing
Django Rest Framework basic auth vs Apache 2.4 Basic Auth - Where is my API request being authenticated?
1
I have a basic DRF API incorporated into to a basic Django application, hosted on Apache 2.4.
In the Apache configs, I give authorization/access to the application to anyone on our local server, with an additional basic authentication set-up (for testing) to allow an API call from an outside server to interact with some models.
When I make a GET request to the application itself with Basic Auth credentials, I get a 200 response with content (I am denied if I do not include credentials). But when I make a GET request to a DRF API endpoint, I get a 401 Unauthorized response. The 401 suggests that the response is not being authenticated.
My question is - why would (or how does) a DRF oriented API call go looking for authentication credentials in a different location than a call to the django app itself (if that's indeed what's going on)?
The Apache configuration looks like this:
DocumentRoot /var/www/html
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
WSGIDaemonProcess portal python-home=/home/bio_admin/envs/dj python-path=/var/www/portal/html/bpp
WSGIScriptAlias /portal /var/www/portal/html/bpp/bioworks/wsgi.py process-group=portal
WSGIProcessGroup portal
WSGIPassAuthorization On
Alias /static/ /var/www/portal/html/bpp/static/
<Directory /var/www/portal/html>
AuthType Basic
AuthName "portal"
AuthUserFile "/var/www/portal/html/.htpasswd"
Require user bio_admin
Require ip 74.xxx.xxx.x
</Directory>
The DRF part of settings.py file looks like this:
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES' : (
'rest_framework.permissions.IsAuthenticated',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.BasicAuthentication',
)
}
urls.py for the api endpoint as well as the endpoint that returns 200 with proper auth:
from rest_framework.urlpatterns import format_suffix_patterns
urlpatterns = [
path('projects/', views.ProjectsListView.as_view(), name='projects'),
path('api/projects/', views.projectListAPI.as_view())
]
urlpatterns = format_suffix_patterns(urlpatterns)
views.py class for the api in question:
class projectDetailAPI(generics.RetrieveUpdateDestroyAPIView):
queryset = Project.objects.all()
serializer_class = ProjectSerializer
django apache authentication django-rest-framework
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
add a comment |
1
I have a basic DRF API incorporated into to a basic Django application, hosted on Apache 2.4.
In the Apache configs, I give authorization/access to the application to anyone on our local server, with an additional basic authentication set-up (for testing) to allow an API call from an outside server to interact with some models.
When I make a GET request to the application itself with Basic Auth credentials, I get a 200 response with content (I am denied if I do not include credentials). But when I make a GET request to a DRF API endpoint, I get a 401 Unauthorized response. The 401 suggests that the response is not being authenticated.
My question is - why would (or how does) a DRF oriented API call go looking for authentication credentials in a different location than a call to the django app itself (if that's indeed what's going on)?
The Apache configuration looks like this:
DocumentRoot /var/www/html
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
WSGIDaemonProcess portal python-home=/home/bio_admin/envs/dj python-path=/var/www/portal/html/bpp
WSGIScriptAlias /portal /var/www/portal/html/bpp/bioworks/wsgi.py process-group=portal
WSGIProcessGroup portal
WSGIPassAuthorization On
Alias /static/ /var/www/portal/html/bpp/static/
<Directory /var/www/portal/html>
AuthType Basic
AuthName "portal"
AuthUserFile "/var/www/portal/html/.htpasswd"
Require user bio_admin
Require ip 74.xxx.xxx.x
</Directory>
The DRF part of settings.py file looks like this:
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES' : (
'rest_framework.permissions.IsAuthenticated',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.BasicAuthentication',
)
}
urls.py for the api endpoint as well as the endpoint that returns 200 with proper auth:
from rest_framework.urlpatterns import format_suffix_patterns
urlpatterns = [
path('projects/', views.ProjectsListView.as_view(), name='projects'),
path('api/projects/', views.projectListAPI.as_view())
]
urlpatterns = format_suffix_patterns(urlpatterns)
views.py class for the api in question:
class projectDetailAPI(generics.RetrieveUpdateDestroyAPIView):
queryset = Project.objects.all()
serializer_class = ProjectSerializer
django apache authentication django-rest-framework
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
After DRF receives the credentials in the request,BasicAuthenticationdecodes them and delegates authentication to the backends registered insettings.py. Are you definitely transmitting the username and password in your request to DRF, and are they correctly encoded?
– Will Keeling
Nov 19 '18 at 20:37
I am transmitting the auth credentials in the same way for the api endpoint and the regular list view url. Using httpie:http -a user:pass http://ip/path/to/url. The only thing that changes between a GET request that returns 200 and a GET request that returns 401 is the url. The encoded passwords are stored in the.htpasswdfile shown in the Apache config. It may be obvious but I am not attempting to authenticate against a user/pass in any associated database, but am using only the user:pass in the.htpasswdfile.
– tschlachter
Nov 19 '18 at 21:03
When you tell DRF to use BasicAuthentication, you are telling DRF to do the authentication. Havingrest_framework.authentication.BasicAuthenticationmeans that you have Apache doing authentication, but then you want to authenticate a second time with Django. You probably should have one or the other. I'd recommend using Django instead, because then each editor of the system can have a unique user id.
– Ross Rogers
Nov 19 '18 at 23:43
I understand the benefits of having user authentication in django. However, the app doesn't have a defined set of users. Access should only be granted to requests coming from the local server IP, with the exception being a list of authenticated users when calling from outside the IP. It seems like limiting by IP would be a task that Apache is better suited for. I set the 'DEFAULT_PERMISSION_CLASSES' and 'DEFAULT_AUTHENTICATION_CLASSES' to blank arrays and have gotten through with Apache auth, thank you. Removing the REST_FRAMEWORK settings entirely returned a 403.
– tschlachter
Nov 20 '18 at 0:10
Perfect. Yeah, omittingDEFAULT_PERMISSION_CLASSESdoes not mean you have an empty permission_classes set. It means that the settings provided by DRF are used instead of whatever you are overriding them as. Good luck!
– Ross Rogers
Nov 20 '18 at 20:01
add a comment |
1
1
1
I have a basic DRF API incorporated into to a basic Django application, hosted on Apache 2.4.
In the Apache configs, I give authorization/access to the application to anyone on our local server, with an additional basic authentication set-up (for testing) to allow an API call from an outside server to interact with some models.
When I make a GET request to the application itself with Basic Auth credentials, I get a 200 response with content (I am denied if I do not include credentials). But when I make a GET request to a DRF API endpoint, I get a 401 Unauthorized response. The 401 suggests that the response is not being authenticated.
My question is - why would (or how does) a DRF oriented API call go looking for authentication credentials in a different location than a call to the django app itself (if that's indeed what's going on)?
The Apache configuration looks like this:
DocumentRoot /var/www/html
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
WSGIDaemonProcess portal python-home=/home/bio_admin/envs/dj python-path=/var/www/portal/html/bpp
WSGIScriptAlias /portal /var/www/portal/html/bpp/bioworks/wsgi.py process-group=portal
WSGIProcessGroup portal
WSGIPassAuthorization On
Alias /static/ /var/www/portal/html/bpp/static/
<Directory /var/www/portal/html>
AuthType Basic
AuthName "portal"
AuthUserFile "/var/www/portal/html/.htpasswd"
Require user bio_admin
Require ip 74.xxx.xxx.x
</Directory>
The DRF part of settings.py file looks like this:
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES' : (
'rest_framework.permissions.IsAuthenticated',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.BasicAuthentication',
)
}
urls.py for the api endpoint as well as the endpoint that returns 200 with proper auth:
from rest_framework.urlpatterns import format_suffix_patterns
urlpatterns = [
path('projects/', views.ProjectsListView.as_view(), name='projects'),
path('api/projects/', views.projectListAPI.as_view())
]
urlpatterns = format_suffix_patterns(urlpatterns)
views.py class for the api in question:
class projectDetailAPI(generics.RetrieveUpdateDestroyAPIView):
queryset = Project.objects.all()
serializer_class = ProjectSerializer
django apache authentication django-rest-framework
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
I have a basic DRF API incorporated into to a basic Django application, hosted on Apache 2.4.
In the Apache configs, I give authorization/access to the application to anyone on our local server, with an additional basic authentication set-up (for testing) to allow an API call from an outside server to interact with some models.
When I make a GET request to the application itself with Basic Auth credentials, I get a 200 response with content (I am denied if I do not include credentials). But when I make a GET request to a DRF API endpoint, I get a 401 Unauthorized response. The 401 suggests that the response is not being authenticated.
My question is - why would (or how does) a DRF oriented API call go looking for authentication credentials in a different location than a call to the django app itself (if that's indeed what's going on)?
The Apache configuration looks like this:
DocumentRoot /var/www/html
LoadModule wsgi_module /usr/lib/apache2/modules/mod_wsgi.so
WSGIDaemonProcess portal python-home=/home/bio_admin/envs/dj python-path=/var/www/portal/html/bpp
WSGIScriptAlias /portal /var/www/portal/html/bpp/bioworks/wsgi.py process-group=portal
WSGIProcessGroup portal
WSGIPassAuthorization On
Alias /static/ /var/www/portal/html/bpp/static/
<Directory /var/www/portal/html>
AuthType Basic
AuthName "portal"
AuthUserFile "/var/www/portal/html/.htpasswd"
Require user bio_admin
Require ip 74.xxx.xxx.x
</Directory>
The DRF part of settings.py file looks like this:
REST_FRAMEWORK = {
'DEFAULT_PERMISSION_CLASSES' : (
'rest_framework.permissions.IsAuthenticated',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.BasicAuthentication',
)
}
urls.py for the api endpoint as well as the endpoint that returns 200 with proper auth:
from rest_framework.urlpatterns import format_suffix_patterns
urlpatterns = [
path('projects/', views.ProjectsListView.as_view(), name='projects'),
path('api/projects/', views.projectListAPI.as_view())
]
urlpatterns = format_suffix_patterns(urlpatterns)
views.py class for the api in question:
class projectDetailAPI(generics.RetrieveUpdateDestroyAPIView):
queryset = Project.objects.all()
serializer_class = ProjectSerializer
django apache authentication django-rest-framework
django apache authentication django-rest-framework
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
asked Nov 19 '18 at 19:39
tschlachtertschlachter
62
62
After DRF receives the credentials in the request,BasicAuthenticationdecodes them and delegates authentication to the backends registered insettings.py. Are you definitely transmitting the username and password in your request to DRF, and are they correctly encoded?
– Will Keeling
Nov 19 '18 at 20:37
I am transmitting the auth credentials in the same way for the api endpoint and the regular list view url. Using httpie:http -a user:pass http://ip/path/to/url. The only thing that changes between a GET request that returns 200 and a GET request that returns 401 is the url. The encoded passwords are stored in the.htpasswdfile shown in the Apache config. It may be obvious but I am not attempting to authenticate against a user/pass in any associated database, but am using only the user:pass in the.htpasswdfile.
– tschlachter
Nov 19 '18 at 21:03
When you tell DRF to use BasicAuthentication, you are telling DRF to do the authentication. Havingrest_framework.authentication.BasicAuthenticationmeans that you have Apache doing authentication, but then you want to authenticate a second time with Django. You probably should have one or the other. I'd recommend using Django instead, because then each editor of the system can have a unique user id.
– Ross Rogers
Nov 19 '18 at 23:43
I understand the benefits of having user authentication in django. However, the app doesn't have a defined set of users. Access should only be granted to requests coming from the local server IP, with the exception being a list of authenticated users when calling from outside the IP. It seems like limiting by IP would be a task that Apache is better suited for. I set the 'DEFAULT_PERMISSION_CLASSES' and 'DEFAULT_AUTHENTICATION_CLASSES' to blank arrays and have gotten through with Apache auth, thank you. Removing the REST_FRAMEWORK settings entirely returned a 403.
– tschlachter
Nov 20 '18 at 0:10
Perfect. Yeah, omittingDEFAULT_PERMISSION_CLASSESdoes not mean you have an empty permission_classes set. It means that the settings provided by DRF are used instead of whatever you are overriding them as. Good luck!
– Ross Rogers
Nov 20 '18 at 20:01
add a comment |
After DRF receives the credentials in the request,BasicAuthenticationdecodes them and delegates authentication to the backends registered insettings.py. Are you definitely transmitting the username and password in your request to DRF, and are they correctly encoded?
– Will Keeling
Nov 19 '18 at 20:37
I am transmitting the auth credentials in the same way for the api endpoint and the regular list view url. Using httpie:http -a user:pass http://ip/path/to/url. The only thing that changes between a GET request that returns 200 and a GET request that returns 401 is the url. The encoded passwords are stored in the.htpasswdfile shown in the Apache config. It may be obvious but I am not attempting to authenticate against a user/pass in any associated database, but am using only the user:pass in the.htpasswdfile.
– tschlachter
Nov 19 '18 at 21:03
When you tell DRF to use BasicAuthentication, you are telling DRF to do the authentication. Havingrest_framework.authentication.BasicAuthenticationmeans that you have Apache doing authentication, but then you want to authenticate a second time with Django. You probably should have one or the other. I'd recommend using Django instead, because then each editor of the system can have a unique user id.
– Ross Rogers
Nov 19 '18 at 23:43
I understand the benefits of having user authentication in django. However, the app doesn't have a defined set of users. Access should only be granted to requests coming from the local server IP, with the exception being a list of authenticated users when calling from outside the IP. It seems like limiting by IP would be a task that Apache is better suited for. I set the 'DEFAULT_PERMISSION_CLASSES' and 'DEFAULT_AUTHENTICATION_CLASSES' to blank arrays and have gotten through with Apache auth, thank you. Removing the REST_FRAMEWORK settings entirely returned a 403.
– tschlachter
Nov 20 '18 at 0:10
Perfect. Yeah, omittingDEFAULT_PERMISSION_CLASSESdoes not mean you have an empty permission_classes set. It means that the settings provided by DRF are used instead of whatever you are overriding them as. Good luck!
– Ross Rogers
Nov 20 '18 at 20:01
After DRF receives the credentials in the request,
BasicAuthentication decodes them and delegates authentication to the backends registered in settings.py. Are you definitely transmitting the username and password in your request to DRF, and are they correctly encoded?– Will Keeling
Nov 19 '18 at 20:37
After DRF receives the credentials in the request,
BasicAuthentication decodes them and delegates authentication to the backends registered in settings.py. Are you definitely transmitting the username and password in your request to DRF, and are they correctly encoded?– Will Keeling
Nov 19 '18 at 20:37
I am transmitting the auth credentials in the same way for the api endpoint and the regular list view url. Using httpie:
http -a user:pass http://ip/path/to/url . The only thing that changes between a GET request that returns 200 and a GET request that returns 401 is the url. The encoded passwords are stored in the .htpasswd file shown in the Apache config. It may be obvious but I am not attempting to authenticate against a user/pass in any associated database, but am using only the user:pass in the .htpasswd file.– tschlachter
Nov 19 '18 at 21:03
I am transmitting the auth credentials in the same way for the api endpoint and the regular list view url. Using httpie:
http -a user:pass http://ip/path/to/url . The only thing that changes between a GET request that returns 200 and a GET request that returns 401 is the url. The encoded passwords are stored in the .htpasswd file shown in the Apache config. It may be obvious but I am not attempting to authenticate against a user/pass in any associated database, but am using only the user:pass in the .htpasswd file.– tschlachter
Nov 19 '18 at 21:03
When you tell DRF to use BasicAuthentication, you are telling DRF to do the authentication. Having
rest_framework.authentication.BasicAuthentication means that you have Apache doing authentication, but then you want to authenticate a second time with Django. You probably should have one or the other. I'd recommend using Django instead, because then each editor of the system can have a unique user id.– Ross Rogers
Nov 19 '18 at 23:43
When you tell DRF to use BasicAuthentication, you are telling DRF to do the authentication. Having
rest_framework.authentication.BasicAuthentication means that you have Apache doing authentication, but then you want to authenticate a second time with Django. You probably should have one or the other. I'd recommend using Django instead, because then each editor of the system can have a unique user id.– Ross Rogers
Nov 19 '18 at 23:43
I understand the benefits of having user authentication in django. However, the app doesn't have a defined set of users. Access should only be granted to requests coming from the local server IP, with the exception being a list of authenticated users when calling from outside the IP. It seems like limiting by IP would be a task that Apache is better suited for. I set the 'DEFAULT_PERMISSION_CLASSES' and 'DEFAULT_AUTHENTICATION_CLASSES' to blank arrays and have gotten through with Apache auth, thank you. Removing the REST_FRAMEWORK settings entirely returned a 403.
– tschlachter
Nov 20 '18 at 0:10
I understand the benefits of having user authentication in django. However, the app doesn't have a defined set of users. Access should only be granted to requests coming from the local server IP, with the exception being a list of authenticated users when calling from outside the IP. It seems like limiting by IP would be a task that Apache is better suited for. I set the 'DEFAULT_PERMISSION_CLASSES' and 'DEFAULT_AUTHENTICATION_CLASSES' to blank arrays and have gotten through with Apache auth, thank you. Removing the REST_FRAMEWORK settings entirely returned a 403.
– tschlachter
Nov 20 '18 at 0:10
Perfect. Yeah, omitting
DEFAULT_PERMISSION_CLASSES does not mean you have an empty permission_classes set. It means that the settings provided by DRF are used instead of whatever you are overriding them as. Good luck!– Ross Rogers
Nov 20 '18 at 20:01
Perfect. Yeah, omitting
DEFAULT_PERMISSION_CLASSES does not mean you have an empty permission_classes set. It means that the settings provided by DRF are used instead of whatever you are overriding them as. Good luck!– Ross Rogers
Nov 20 '18 at 20:01
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381523%2fdjango-rest-framework-basic-auth-vs-apache-2-4-basic-auth-where-is-my-api-requ%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
draft saved
draft discarded
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
draft saved
draft discarded
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53381523%2fdjango-rest-framework-basic-auth-vs-apache-2-4-basic-auth-where-is-my-api-requ%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
After DRF receives the credentials in the request,
BasicAuthenticationdecodes them and delegates authentication to the backends registered insettings.py. Are you definitely transmitting the username and password in your request to DRF, and are they correctly encoded?– Will Keeling
Nov 19 '18 at 20:37
I am transmitting the auth credentials in the same way for the api endpoint and the regular list view url. Using httpie:
http -a user:pass http://ip/path/to/url. The only thing that changes between a GET request that returns 200 and a GET request that returns 401 is the url. The encoded passwords are stored in the.htpasswdfile shown in the Apache config. It may be obvious but I am not attempting to authenticate against a user/pass in any associated database, but am using only the user:pass in the.htpasswdfile.– tschlachter
Nov 19 '18 at 21:03
When you tell DRF to use BasicAuthentication, you are telling DRF to do the authentication. Having
rest_framework.authentication.BasicAuthenticationmeans that you have Apache doing authentication, but then you want to authenticate a second time with Django. You probably should have one or the other. I'd recommend using Django instead, because then each editor of the system can have a unique user id.– Ross Rogers
Nov 19 '18 at 23:43
I understand the benefits of having user authentication in django. However, the app doesn't have a defined set of users. Access should only be granted to requests coming from the local server IP, with the exception being a list of authenticated users when calling from outside the IP. It seems like limiting by IP would be a task that Apache is better suited for. I set the 'DEFAULT_PERMISSION_CLASSES' and 'DEFAULT_AUTHENTICATION_CLASSES' to blank arrays and have gotten through with Apache auth, thank you. Removing the REST_FRAMEWORK settings entirely returned a 403.
– tschlachter
Nov 20 '18 at 0:10
Perfect. Yeah, omitting
DEFAULT_PERMISSION_CLASSESdoes not mean you have an empty permission_classes set. It means that the settings provided by DRF are used instead of whatever you are overriding them as. Good luck!– Ross Rogers
Nov 20 '18 at 20:01