My Django site uses the LDAP backend for authentication in production, but this is not suitable for testing (impossible to create requests from dummy users). How can I disable this backend, solely for tests?
Here is the relevant settings.py section:
AUTHENTICATION_BACKENDS = (
#'crowd.backend.CrowdBackend',
# 'django_auth_ldap.backend.LDAPBackend',
'django.contrib.auth.backends.ModelBackend',
)
AUTH_LDAP_SERVER_URI = "ldap://ldap.cablelabs.com"
import ldap
from django_auth_ldap.config import LDAPSearch
AUTH_LDAP_BIND_DN = "CN=CableLabs Internal,OU=cabletest,OU=Teamwork,OU=community,DC=cablelabs,DC=com"
AUTH_LDAP_BIND_PASSWORD = "UAq,0#ki"
AUTH_LDAP_USER_SEARCH = LDAPSearch("ou=community,dc=cablelabs,dc=com",ldap.SCOPE_SUBTREE, "(sAMAccountName=%(user)s)")
AUTH_LDAP_USER_ATTR_MAP = {"first_name": "givenName", "last_name": "sn","username":"sAMAccountName","email":"mail","photo":"thumbnailPhoto"}
AUTH_LDAP_CONNECTION_OPTIONS = {
ldap.OPT_REFERRALS: 0
}
If you only need/want to disable the backend for certain tests, you can also use the override_settings decorator. You can use this decorator on the test case class:
from django.test.utils import override_settings
#override_settings(AUTHENTICATION_BACKENDS=
('django.contrib.auth.backends.ModelBackend',))
class FooTest(TestCase):
def test_bar(self):
pass
But you can also selectively use it on a test method:
from django.test.utils import override_settings
class FooTest(TestCase):
#override_settings(AUTHENTICATION_BACKENDS=
('django.contrib.auth.backends.ModelBackend',))
def test_bar(self):
pass
Create an alternative settings file, for example myproj/test_settings.py, and specify that settings file when running unit tests.
Write the alternative settings file like this:
from myproj.settings import *
AUTHENTICATION_BACKENDS = (
#'your.ldap.backend',
'django.contrib.auth.backends.ModelBackend',
)
That is, the settings inherits everything from your regular settings, but overrides the AUTHENTICATION_BACKENDS definition, with your LDAP backend commented out.
Then, run your tests like this:
python manage.py test --settings=myproj.test_settings
For future reference, another option to look into for testing is to change the is_authenticated property of the User object to a lambda. For example:
user = User(...)
user.is_authenticated = lambda: True
Related
Currently using a REST API and the generic views CreateUpdateDestroy, and my admin display GUI looks like this :
All the sources online that I've followed, tutorials etc get a generic view which looks much nicer.
Here is my views.py:
from rest_framework import generics
from models import Results
from serializers import ResulutsSerializer
class ResultsList(generics.ListAPIView):
queryset = Results.objects.all()
serializer_class = ResultsSerializer
class ResultsDetail(generics.RetrieveUpdateDestroyAPIView):
queryset = Results.objects.all()
serializer_class = ResultsSerializer
and urls.py:
from django.urls import path
from main import views
urlpatterns = [
path('results/', views.ResultsList.as_view()),
path('<int:pk>/', views.ResultsDetails.as_view())
]
what am I doing wrong?
It looks like you need to collect your app assets:
$ python manage.py collectstatic
# You can provide option: --settings=<your-settings-file> if you're using custom settings which is not default in manage.py
You will need to configure staticfiles settings in your Django settings module if not already configured – e.g. settings.py. Please follow documentation at:
https://docs.djangoproject.com/en/2.0/howto/static-files/
https://docs.djangoproject.com/en/2.0/ref/contrib/staticfiles/
If you are developing locally:
You should set DEBUG=True in your Django Settings Module (i.e. normally settings.py)
My Django ( Django 1.11) project is using django-auth-ldap 1.2 as authentication backed.
I have no problem to authenticate any user agents LDAP database using:
#login_required(login_url='/accounts/login/')
and in this case, any user from any group can login to the site.
I want to allow only user from 'group1' to be able to access the website.
I used the code listed below
from django.shortcuts import render
from django.template import loader
from django.http import HttpResponse
from django.contrib.auth.decorators import login_required
from django.contrib.auth import views as auth_views
#user_passes_test(
lambda u: hasattr(u, 'ldap_user') and 'group1' in u.ldap_user.group_names,
login_url='/accounts/login/')
def index(request):
template = loader.get_template('main/index.html')
return HttpResponse(template.render())
This is code is not working and user will never pass the test.
According to the model documents django-auth-ldap Document I can use ldap_user.group_names to get group names of a user.
Here is my ldap settings from settings.py:
import os
import django
AUTHENTICATION_BACKENDS = ('django_auth_ldap.backend.LDAPBackend',)
import ldap
from django_auth_ldap.config import LDAPSearch, GroupOfNamesType
AUTH_LDAP_SERVER_URI = "ldap://mydomain.com"
AUTH_LDAP_BIND_DN = "cn=admin,dc=mydomain,dc=com"
AUTH_LDAP_BIND_PASSWORD = "mypass"
AUTH_LDAP_USER_SEARCH = LDAPSearch("ou=ou_org_unit,dc=mydomain,dc=com",
ldap.SCOPE_SUBTREE, "(uid=%(user)s)")
AUTH_LDAP_GROUP_SEARCH = LDAPSearch("ou=ou_org_unit,cn=group1,cn=group2,dc=mydomain,dc=com",
ldap.SCOPE_SUBTREE, "(objectClass=groupOfNames)"
)
AUTH_LDAP_GROUP_TYPE = GroupOfNamesType()
AUTH_LDAP_USER_ATTR_MAP = {
"first_name": "givenName",
"last_name": "sn",
"email": "mail"
}
AUTH_LDAP_FIND_GROUP_PERMS = True
AUTH_LDAP_CACHE_GROUPS = True
AUTH_LDAP_GROUP_CACHE_TIMEOUT = 3600
My question is:
Why I am not able to authenticate any user with this code?
You should be using the AUTH_LDAP_REQUIRE_GROUP setting if you want to restrict logins to a single group.
You will also likely want to use AUTH_LDAP_MIRROR_GROUPS in order to have all of your LDAP groups automatically loaded into your Django database.
As a bonus, you can include multiple groups in the AUTH_LDAP_REQUIRE_GROUP setting, by using the LDAPGroupQuery class. For example (taken from the documentation):
from django_auth_ldap.config import LDAPGroupQuery
AUTH_LDAP_REQUIRE_GROUP = (
(
LDAPGroupQuery("cn=enabled,ou=groups,dc=example,dc=com") |
LDAPGroupQuery("cn=also_enabled,ou=groups,dc=example,dc=com")
) &
~LDAPGroupQuery("cn=disabled,ou=groups,dc=example,dc=com")
)
I basically want to turn TokenAuthentication on but only for 2 unit tests. The only option I've seen so far is to use #override_settings(...) to replace the REST_FRAMEWORK settings value.
REST_FRAMEWORK_OVERRIDE={
'PAGINATE_BY': 20,
'TEST_REQUEST_DEFAULT_FORMAT': 'json',
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.JSONRenderer',
'rest_framework_csv.renderers.CSVRenderer',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
),
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.IsAuthenticated',
),
}
#override_settings(REST_FRAMEWORK=REST_FRAMEWORK_OVERRIDE)
def test_something(self):
This isn't working. I can print the settings before and after the decorator and see that the values changed but django doesn't seem to be respecting them. It allows all requests sent using the test Client or the DRF APIClient object through without authentication. I'm getting 200 responses when I would expect 401 unauthorized.
If I insert that same dictionary into my test_settings.py file in the config folder everything works as expected. However like I said I only want to turn on authentication for a couple of unit tests, not all of them. My thought is that Django never revisits the settings for DRF after initialization. So even though the setting values are correct they are not used.
Has anyone run into this problem and found a solution? Or workaround?
The following workaround works well for me:
from rest_framework.views import APIView
from rest_framework.permissions import IsAuthenticatedOrReadOnly
from rest_framework.authentication import TokenAuthentication
try:
from unittest.mock import patch
except ImportError:
from mock import patch
#patch.object(APIView, 'authentication_classes', new = [TokenAuthentication])
#patch.object(APIView, 'permission_classes', new = [IsAuthenticatedOrReadOnly])
class AuthClientTest(LiveServerTestCase):
# your tests goes here
Just thought I'd mention how I solved this. It's not pretty and if anyone has any suggestions to clean it up they are more than welcome! As I mentioned earlier the problem I'm having is documented here (https://github.com/tomchristie/django-rest-framework/issues/2466), but the fix is not so clear. In addition to reloading the DRF views module I also had to reload the apps views module to get it working.
import os
import json
from django.conf import settings
from django.test.utils import override_settings
from django.utils.six.moves import reload_module
from rest_framework import views as drf_views
from rest_framework.test import force_authenticate, APIRequestFactory, APIClient
from apps.contact import views as cm_views
from django.core.urlresolvers import reverse
from django.test import TestCase
from unittest import mock
REST_FRAMEWORK_OVERRIDE={
'PAGINATE_BY': 20,
'TEST_REQUEST_DEFAULT_FORMAT': 'json',
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.JSONRenderer',
'rest_framework_csv.renderers.CSVRenderer',
),
'DEFAULT_AUTHENTICATION_CLASSES': (
'rest_framework.authentication.TokenAuthentication',
),
'DEFAULT_PERMISSION_CLASSES': (
'rest_framework.permissions.IsAuthenticated',
),
}
def test_authenticated(self):
with override_settings(REST_FRAMEWORK=REST_FRAMEWORK_OVERRIDE):
# The two lines below will make sure the views have the correct authentication_classes and permission_classes
reload_module(drf_views)
reload_module(cm_views)
from apps.contact.views import AccountView
UserModelGet = mock.Mock(return_value=self.account)
factory = APIRequestFactory()
user = UserModelGet(user='username')
view = AccountView.as_view()
# Test non existent account
path = self.get_account_path("1thiswillneverexist")
request = factory.get(path)
force_authenticate(request, user=user)
response = view(request, account_name=os.path.basename(request.path))
self.assertEquals(response.status_code, 200, "Wrong status code")
self.assertEqual(json.loads(str(response.content, encoding='utf-8')), [], "Content not correct for authenticated account request")
# Reset the views permission_classes and authentication_classes to what they were before this test
reload_module(cm_views)
reload_module(drf_views)
Wow that's annoying.
Here's a generic contextmanager that handles the reloading. Note that you can't import the subobject api_settings directly because DRF doesn't alter it on reload, but rather reassigns the module-level object to a new instance, so we just access it from the module directly when we need it.
from rest_framework import settings as api_conf
#contextmanager
def override_rest_framework_settings(new_settings):
with override_settings(REST_FRAMEWORK=new_settings):
# NOTE: `reload_api_settings` is a signal handler, so we have to pass a
# couple things in to get it working.
api_conf.reload_api_settings(setting="REST_FRAMEWORK", value="")
with mock.patch.multiple(
"rest_framework.views.APIView",
authentication_classes=api_conf.api_settings.DEFAULT_AUTHENTICATION_CLASSES,
):
yield
api_conf.reload_api_settings(setting="REST_FRAMEWORK", value="")
NOTE: If you're changing other aspects of the settings, you may also have to patch the following APIView attributes:
renderer_classes = api_settings.DEFAULT_RENDERER_CLASSES
parser_classes = api_settings.DEFAULT_PARSER_CLASSES
authentication_classes = api_settings.DEFAULT_AUTHENTICATION_CLASSES
throttle_classes = api_settings.DEFAULT_THROTTLE_CLASSES
permission_classes = api_settings.DEFAULT_PERMISSION_CLASSES
content_negotiation_class = api_settings.DEFAULT_CONTENT_NEGOTIATION_CLASS
metadata_class = api_settings.DEFAULT_METADATA_CLASS
versioning_class = api_settings.DEFAULT_VERSIONING_CLASS
settings = api_settings
How can I disable a specific middleware (a custom middleware I wrote) only during tests?
Also related (since this page ranks quite high in search engines for relates queries):
If you'd only like to disable a middleware for a single case, you can also use #modify_settings:
#modify_settings(MIDDLEWARE={
'remove': 'django.middleware.cache.FetchFromCacheMiddleware',
})
def test_my_function(self):
pass
https://docs.djangoproject.com/en/dev/topics/testing/tools/#django.test.override_settings
from django.test import TestCase, override_settings
from django.conf import settings
class MyTestCase(TestCase):
#override_settings(
MIDDLEWARE_CLASSES=[mc for mc in settings.MIDDLEWARE_CLASSES
if mc != 'myapp.middleware.MyMiddleware']
)
def test_my_function(self):
pass
There are several options:
create a separate test_settings settings file for testing and then run tests via:
python manage.py test --settings=test_settings
modify your settings.py on the fly if test is in sys.argv
if 'test' in sys.argv:
# modify MIDDLEWARE_CLASSES
MIDDLEWARE_CLASSES = list(MIDDLEWARE_CLASSES)
MIDDLEWARE_CLASSES.remove(<middleware_to_disable>)
Hope that helps.
A nice way to handle this with a single point of modification is to create a conftest.py file at the root of Django project and the put the following contents in it:
from django.conf import settings
def pytest_configure():
"""Globally remove the your_middleware_to_remove for all tests"""
settings.MIDDLEWARE.remove(
'your_middleware_to_remove')
Is there any simple mechanism for overriding Django settings for a unit test? I have a manager on one of my models that returns a specific number of the latest objects. The number of objects it returns is defined by a NUM_LATEST setting.
This has the potential to make my tests fail if someone were to change the setting. How can I override the settings on setUp() and subsequently restore them on tearDown()? If that isn't possible, is there some way I can monkey patch the method or mock the settings?
EDIT: Here is my manager code:
class LatestManager(models.Manager):
"""
Returns a specific number of the most recent public Articles as defined by
the NEWS_LATEST_MAX setting.
"""
def get_query_set(self):
num_latest = getattr(settings, 'NEWS_NUM_LATEST', 10)
return super(LatestManager, self).get_query_set().filter(is_public=True)[:num_latest]
The manager uses settings.NEWS_LATEST_MAX to slice the queryset. The getattr() is simply used to provide a default should the setting not exist.
EDIT: This answer applies if you want to change settings for a small number of specific tests.
Since Django 1.4, there are ways to override settings during tests:
https://docs.djangoproject.com/en/stable/topics/testing/tools/#overriding-settings
TestCase will have a self.settings context manager, and there will also be an #override_settings decorator that can be applied to either a test method or a whole TestCase subclass.
These features did not exist yet in Django 1.3.
If you want to change settings for all your tests, you'll want to create a separate settings file for test, which can load and override settings from your main settings file. There are several good approaches to this in the other answers; I have seen successful variations on both hspander's and dmitrii's approaches.
You can do anything you like to the UnitTest subclass, including setting and reading instance properties:
from django.conf import settings
class MyTest(unittest.TestCase):
def setUp(self):
self.old_setting = settings.NUM_LATEST
settings.NUM_LATEST = 5 # value tested against in the TestCase
def tearDown(self):
settings.NUM_LATEST = self.old_setting
Since the django test cases run single-threaded, however, I'm curious about what else may be modifying the NUM_LATEST value? If that "something else" is triggered by your test routine, then I'm not sure any amount of monkey patching will save the test without invalidating the veracity of the tests itself.
You can pass --settings option when running tests
python manage.py test --settings=mysite.settings_local
Although overriding settings configuration on runtime might help, in my opinion you should create a separate file for testing. This saves lot of configuration for testing and this would ensure that you never end up doing something irreversible (like cleaning staging database).
Say your testing file exists in 'my_project/test_settings.py', add
settings = 'my_project.test_settings' if 'test' in sys.argv else 'my_project.settings'
in your manage.py. This will ensure that when you run python manage.py test you use test_settings only. If you are using some other testing client like pytest, you could as easily add this to pytest.ini
Update: the solution below is only needed on Django 1.3.x and earlier. For >1.4 see slinkp's answer.
If you change settings frequently in your tests and use Python ≥2.5, this is also handy:
from contextlib import contextmanager
class SettingDoesNotExist:
pass
#contextmanager
def patch_settings(**kwargs):
from django.conf import settings
old_settings = []
for key, new_value in kwargs.items():
old_value = getattr(settings, key, SettingDoesNotExist)
old_settings.append((key, old_value))
setattr(settings, key, new_value)
yield
for key, old_value in old_settings:
if old_value is SettingDoesNotExist:
delattr(settings, key)
else:
setattr(settings, key, old_value)
Then you can do:
with patch_settings(MY_SETTING='my value', OTHER_SETTING='other value'):
do_my_tests()
You can override setting even for a single test function.
from django.test import TestCase, override_settings
class SomeTestCase(TestCase):
#override_settings(SOME_SETTING="some_value")
def test_some_function():
or you can override setting for each function in class.
#override_settings(SOME_SETTING="some_value")
class SomeTestCase(TestCase):
def test_some_function():
#override_settings is great if you don't have many differences between your production and testing environment configurations.
In other case you'd better just have different settings files. In this case your project will look like this:
your_project
your_app
...
settings
__init__.py
base.py
dev.py
test.py
production.py
manage.py
So you need to have your most of your settings in base.py and then in other files you need to import all everything from there, and override some options. Here's what your test.py file will look like:
from .base import *
DEBUG = False
DATABASES = {
'default': {
'ENGINE': 'django.db.backends.sqlite3',
'NAME': 'app_db_test'
}
}
PASSWORD_HASHERS = (
'django.contrib.auth.hashers.MD5PasswordHasher',
)
LOGGING = {}
And then you either need to specify --settings option as in #MicroPyramid answer, or specify DJANGO_SETTINGS_MODULE environment variable and then you can run your tests:
export DJANGO_SETTINGS_MODULE=settings.test
python manage.py test
For pytest users.
The biggest issue is:
override_settings doesn't work with pytest.
Subclassing Django's TestCase will make it work but then you can't use pytest fixtures.
The solution is to use the settings fixture documented here.
Example
def test_with_specific_settings(settings):
settings.DEBUG = False
settings.MIDDLEWARE = []
..
And in case you need to update multiple fields
def override_settings(settings, kwargs):
for k, v in kwargs.items():
setattr(settings, k, v)
new_settings = dict(
DEBUG=True,
INSTALLED_APPS=[],
)
def test_with_specific_settings(settings):
override_settings(settings, new_settings)
I created a new settings_test.py file which would import everything from settings.py file and modify whatever is different for testing purpose.
In my case I wanted to use a different cloud storage bucket when testing.
settings_test.py:
from project1.settings import *
import os
CLOUD_STORAGE_BUCKET = 'bucket_name_for_testing'
manage.py:
def main():
# use seperate settings.py for tests
if 'test' in sys.argv:
print('using settings_test.py')
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project1.settings_test')
else:
os.environ.setdefault('DJANGO_SETTINGS_MODULE', 'project1.settings')
try:
from django.core.management import execute_from_command_line
except ImportError as exc:
raise ImportError(
"Couldn't import Django. Are you sure it's installed and "
"available on your PYTHONPATH environment variable? Did you "
"forget to activate a virtual environment?"
) from exc
execute_from_command_line(sys.argv)
Found this while trying to fix some doctests... For completeness I want to mention that if you're going to modify the settings when using doctests, you should do it before importing anything else...
>>> from django.conf import settings
>>> settings.SOME_SETTING = 20
>>> # Your other imports
>>> from django.core.paginator import Paginator
>>> # etc
I'm using pytest.
I managed to solve this the following way:
import django
import app.setting
import modules.that.use.setting
# do some stuff with default setting
setting.VALUE = "some value"
django.setup()
import importlib
importlib.reload(app.settings)
importlib.reload(modules.that.use.setting)
# do some stuff with settings new value
You can override settings in test in this way:
from django.test import TestCase, override_settings
test_settings = override_settings(
DEFAULT_FILE_STORAGE='django.core.files.storage.FileSystemStorage',
PASSWORD_HASHERS=(
'django.contrib.auth.hashers.UnsaltedMD5PasswordHasher',
)
)
#test_settings
class SomeTestCase(TestCase):
"""Your test cases in this class"""
And if you need these same settings in another file you can just directly import test_settings.
If you have multiple test files placed in a subdirectory (python package), you can override settings for all these files based on condition of presence of 'test' string in sys.argv
app
tests
__init__.py
test_forms.py
test_models.py
__init__.py:
import sys
from project import settings
if 'test' in sys.argv:
NEW_SETTINGS = {
'setting_name': value,
'another_setting_name': another_value
}
settings.__dict__.update(NEW_SETTINGS)
Not the best approach. Used it to change Celery broker from Redis to Memory.
One setting for all tests in a testCase
class TestSomthing(TestCase):
def setUp(self, **kwargs):
with self.settings(SETTING_BAR={ALLOW_FOO=True})
yield
override one setting in the testCase
from django.test import override_settings
#override_settings(SETTING_BAR={ALLOW_FOO=False})
def i_need_other_setting(self):
...
Important
Even though you are overriding these settings this will not apply to settings that your server initialize stuff with because it is already initialized, to do that you will need to start django with another setting module.