Django-all-access

-----------------------------------

Encrypted fields for storing the provider configurations and access tokens
now sign the values after encryption to dectect if the key is valid before
attempting to decrypt. This was added thanks to Florian Demmer (fdemmer).

Other small changes include:

- Added Django 1.10 and Python 3.5 to the test suite coverage.
- Updated documentation on Facebook version numbers.
- Update provider fixtures to include the latest version number for Facebook.

-----------------------------------

Minor clean up release which drops support for outdated versions of Django. As
such it also removes the old South migrations and the commands related to
django-social-auth.

- Added support for additional parameters in the redirect view.
- Added support for more complex id lookups in the callback view.
- Additional documentation examples for customizing the views.
- Added support for Django 1.9.
- Tracking code coverage reports with Codecov.io.


Backwards Incompatible Changes
__________________________________

- Python 3.2 is no longer officially supported or tested.
- Django < 1.8 is no longer officially supported or tested.
- requests_oauthlib < 0.4.2 is no longer officially supported.
- ``migrate_social_accounts`` and ``migrate_social_accounts`` commands have been removed.

------------------------------------

- Model updates for Django 1.8 compatibility. Requires a non-DB altering migration.

------------------------------------

- Fixed issue in ``migrate_social_accounts`` where output was overly verbose.
- Fixed issue in ``migrate_social_accounts`` with handling skipped providers.

------------------------------------

This release adds support for 1.7 and the new style migrations. If you are using Django < 1.7
and South >= 1.0 this should continue to work without issue.

For those using Django < 1.7 and South < 1.0 you'll need
to add the ``SOUTH_MIGRATION_MODULES`` setting to point to the old South migrations.

.. code-block:: python

SOUTH_MIGRATION_MODULES = {
'allaccess': 'allaccess.south_migrations',
}

No new migrations were added for this release, but this will be the new location for future migrations. If your
DB tables are up to date from v0.6, upgrading to 1.7 and running::

python manage.py migrate allaccess

should automatically fake the initial migration using the new-style migrations.


Backwards Incompatible Changes
__________________________________

- Python 2.6 is no longer officially supported or tested.

------------------------------------

This release adds a better migration path for moving from django-social-auth and includes changes to support
running on the Google App Engine. There are two South migrations included with this release. To upgrade, you should run::

python manage.py migrate allaccess

More details for this change are noted under the "Backwards Incompatible Changes".

- Added ``migrate_social_accounts`` and ``migrate_social_providers`` management commands to help migrate data from django-social-auth.
- Updated ``Provider`` model for compatibility with running on the Google App Engine. Thanks to Marco Seguri for the report and fix.
- Increased the URL lengths for the fields on the ``Provider`` model. Thanks to Marco Seguri for the fix.
- Added support for serialization of ``Provider`` and ``AccountAccess`` records by natural keys.
- Included a fixture of common providers (Facebook, Twitter, Google, Microsoft Live, Github and Bitbucket). Thanks to Marco Seguri for the initial patch.


Backwards Incompatible Changes
__________________________________

- The ``key`` and ``secret`` columns on ``Provider`` were renamed to ``consumer_key`` and ``consumer_secret``. ``key`` is a reserved property
name when using Google App Engine and ``secret`` was changed as well for consistency. A migration has been added for the change but
if you were referencing the ``key``/``secret`` explicitly in your code those references need to be updated as well.
- ``ProviderManager.enabled`` has been removed. This was a short-cut method for filtering out providers with key or secret values. However,
it doesn't work on Google App Engine. It was only used in a few places internally so it was removed. The equivalent query is
``Provider.objects.filter(consumer_secret__isnull=False, consumer_key__isnull=False)``