Made the necessary changes to ensure the code is Django 2 compatible:

• Made some changes to ensure the code works with Django 1.11 and Django 2.2, as well as updating the test cases to run against both Django 1.11 and Django 2.2
• Updated the README, requirements and other parts of the code to make sure we reference Django 1.11 and higher.
• Made changes to the test cases to ensure we only load the required middleware to test functionality. This should help reduce interference from other middleware.
• Minor code clean up

Refs: PAS-197

Add a ClearSiteDataMiddleware and respective django settings.

CLEAR_SITE_DATA_URL_WHITELIST - whitelist of URLs that Clear-Site-Data response header is applied to (eg. /accounts/logout/) CLEAR_SITE_DATA_DIRECTIVES - what directives to apply (defaults to wildcard)

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Clear-Site-Data

because hardcoding User in a ForeignKey stops people from specifing alternative user models using settings.AUTH_USER_MODEL

This fix silences fields.E301 error raised by Django system check (https://docs.djangoproject.com/en/1.8/ref/checks/#related-fields) for users that, for example, use django-authtools or declare own user models based on django.contrib.auth.models.AbstractUser.

Thanks and best regards :), Marek

This change includes the following:

• PEP8 compliance
• Compliance with a number of recommendations given by the OpenStack style guide and PEP8 Naming
• Style testing with Tox
• Minor documentation formatting fixes
• Refactoring of ContentSecurityPolicyMiddleware._csp_builder to reduce McCabe complexity to below 10.
• Travis config so that auto-testing of pull requests can be set up.

The code style has changed quite significantly. The main motivation behind this is that PEP8 is considered to be a good standard that code should strive to adhere to, however in addition to this, I've reformatted the code to provide clearer diffs in future pull requests.

This setting provides means to whitelist certain pages that are expected to be hosted in an <iframe> while still protecting the rest of the site.

I'd like to migrate to django-security, unfortunately this means two things need to happen (in my codebase/environment, or in the larger project...somewhere)

Currently, with the password expiry middleware enabled, we'll create new PasswordExpiry objects for each user when my tests are run. because auto_now_add=True on PasswordExpiry.password_expiry_date this means that many of my view-based integration tests are failing because all users that get created via models also get their password expired.

If instead of auto_now_add=True there were a default that checked a setting, this could be configurable per installation.

This would save me from re-writing several hundred tests in order to implement this feature, and it would ease the transition into production for my current project.

Hi There,

I have made a quick hack to your code to add support for Django 1.10 as suggested here:

https://docs.djangoproject.com/en/1.10/topics/http/middleware/#upgrading-pre-django-1-10-style-middleware

Thanks

These changes improve handling of CSP reports as tested with real-life browsers. The CspReport model now also records user agent and reporting IP for easier debugging.

New Content-Type should be "application/csp-report" https://w3c.github.io/webappsec-csp/

This should be merged (or fixed otherwise) ASAP because current content_type check breaks CSP reporting from new browsers.

In the latest Django 1.8 + it is not necessary to pass strings as byte arrays in migrations.

This appears to be a legacy code. And because of this, Django's checks for migrations identifies that migrations need to be created, where in fact nothing has changed.

I'm using Django 2.0.2. Since Django 2.x, on_delete is a required argument: https://docs.djangoproject.com/en/2.0/ref/models/fields/#django.db.models.ForeignKey.on_delete

I'm getting the following stack trace when I attempt to instal django-security:

    Unhandled exception in thread started by <function check_errors.<locals>.wrapper at 0x10520c7b8>
Traceback (most recent call last):
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 225, in wrapper
    fn(*args, **kwargs)
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/core/management/commands/runserver.py", line 113, in inner_run
    autoreload.raise_last_exception()
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 248, in raise_last_exception
    raise _exception[1]
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/core/management/__init__.py", line 327, in execute
    autoreload.check_errors(django.setup)()
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/utils/autoreload.py", line 225, in wrapper
    fn(*args, **kwargs)
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/__init__.py", line 24, in setup
    apps.populate(settings.INSTALLED_APPS)
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/apps/registry.py", line 112, in populate
    app_config.import_models()
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/django/apps/config.py", line 198, in import_models
    self.models_module = import_module(models_module_name)
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
  File "<frozen importlib._bootstrap>", line 994, in _gcd_import
  File "<frozen importlib._bootstrap>", line 971, in _find_and_load
  File "<frozen importlib._bootstrap>", line 955, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 665, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 678, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/security/models.py", line 14, in <module>
    class PasswordExpiry(models.Model):
  File "/Users/nina/Documents/Sites/project-name/venv/lib/python3.6/site-packages/security/models.py", line 27, in PasswordExpiry
    user = models.ForeignKey(USER_MODEL, unique=True)
TypeError: __init__() missing 1 required positional argument: 'on_delete'

Closes #87

I've added a test which fails on master and succeeds with this PR.

(I also loosened some of the flake8 restrictions to get existing code to pass. I'd be happy to remove those restrictions and update the code if you prefer)

Django says LOGIN_URL can be a URL or a named URL pattern, but LoginRequiredMiddleware assumes that it is a URL so named URL patterns don't work. I think this could be fixed by running the URL through resolve_url before redirecting.

Hi, I've created a subclass of ContentSecurityPolicyMiddleware and an accompanying template context processor so I can do:

<script type="text/javascript" nonce="{{ csp_nonce }}">
</script>

Is there any interest in this? If so I can make a PR.

Thanks!

I really like the all-in-one convenience of django-security, but the SessionSecurityMiddleware implementation lacks the client-side keep-alive available in django-session-security. The keep-alive is important to us because our product is used to guide a conversation with a customer so our users are often "active" on a page without server-side interaction.

Any interest adding a keep-alive feature to django-security? If so, what approach would you prefer? The licenses look compatible so it seems like any of the following would work:

• Replace SessionSecurityMiddleware with the django-session-security implementation
• Port the JS code to SessionSecurityMiddleware
• Include both in django-security