``django-lazysignup-redux`` is a fork of ``django-lazysignup`` that supportsDjango 1.7 and 1.8 untilhttps://github.com/danfairs/django-lazysignup/pull/44 is merged and released.

``django-lazysignup`` is a package designed to allow users to interact with asite as if they were authenticated users, but without signing up. At any time,they can convert their temporary user account to a real user account.

`Read the full documentation`_.

.. _Read the full documentation: http://django-lazysignup.readthedocs.org/

Tests=====

To run the tests, do the following::

python manage.py test

Changelog=========

1.0.0-----* Add support for Django 1.7 migrations* Drop support for Django 1.6 and earlier* Add tests for custom user model

0.12.2------

Fix another packaging error. Thanks to David Eyk (eykd) for the pull request.

Add compatibility with Django 1.5 and Python 3.3. Note that this does not yetexplicitly support Django 1.5's new pluggable User models in any particularway.

Thanks to Brad Pitcher for this work.

0.11.1------

Fix packaging and docs errors.

0.11.0------

This is a feature release, that requires a data migration. Use theprovided South migration, or add a `created` date/time field to your `LazyUser`model manually. This field will be populated when a `LazyUser` instance iscreated, and is set to the current date/time.

A `test-requirements.txt` file has been added to ease installation of test-onlydependencies.

A new-style DATABASES structure replaces the old DATABASE_* fields.

Versions of Django earlier than 1.4 are no longer supported. Nothing has beendone to explicitly prevent 1.3.x working, but it will no longer be maintained.(Patches to restore support, if it breaks, are welcome.)

0.10.3------

Fix packaging error.

0.10.2------

This is a docs-only release. Docs have converted to Sphinx, for easiernavigation.

0.10.1------

This is a bugfix release, which included some docs omitted from the 0.10.0release.

0.10.0------

This is a feature release. Two new decorators have been added:`@require_lazy_user` and `@require_nonlazy_user`.

Thanks to Brad Beattie (bradbeattie) for the implementation and tests, and toAdam Coddington (latestrevision) for the original suggestion.

0.9.0-----

This is a feature release. A custom signal is now fired when a user isconverted. Thanks to Olly Smith (oesmith) for the patch.

Versions of Django earlier than 1.3 are now no longer supported. (Nothing hasbeen done to prevent 1.2.x working, but I will no longer take care to make surethat this remains the case.)

0.8.0-----

This is a feature release. This contains all the features in the 0.8.0 betaseries, plus the ability to specify custom templates for the convert view,both via a regular GET and via Ajax. Thanks to percyperez for the idea andinitial implementation.

Note that this release is the last feature release that will support Django1.2 or earlier. 0.9.0 and later will require Django 1.3 or later.

0.8.0b2-------

This release introduces the following backwards-incompatible changes:

* A test project was added to make running the tests a little easier. The old way of running the tests has been removed.* The `urls.py` no longer hardcodes `convert` as the URL prefix (thanks to mitar)

0.8.0b1-------

This is a bugfix and feature release. The internal API has changed to nolonger depend on session keys for username generation. This should bebackwards-compatible as long as you are using the documented API.

* Removed the hard dependency on session keys to generate usernames, as it was unnecessary.* remove_expired_users should no longer depend on using the database session backend - it will instead use SESSION_COOKIE_AGE to find lazy users who have not logged in recently and whose sessions will therefore have expired.

You should still not use remove_expired_users without reviewing the code;in particular, you may wish to subclass the command and override`to_delete()`.

These changes are somewhat experimental, so this is a beta release - it is*not* recommended that you run this in production. Testing and feedback iswelcome.

0.7.0-----

This is a feature release. Custom user classes are now supported via the``LAZYSIGNUP_USER_MODEL`` setting. This is a backwards-compatible change.

Thanks to Luke Zapart for the idea and initial implementation.

0.6.2-----

This is a bugfix release. Issues fixed:

* The LazySignupBackend no longer relies on a specific User class to authenticate a user. It now uses the fact that there is a relationship between the LazyUser and the main site User class. This fixes the bug where authenticate() was looking directly for UNUSABLE_PASSWORD, and also paves the way for custom user classes.

0.6.1-----

This is a bugfix release. Issues fixed:

* https://github.com/danfairs/django-lazysignup/issues#issue/2 - Invalid user IDs in the session could cause an AttributeError from the auth backend.

Thanks to Alex Ehlke for the report and patch.

0.6.0-----

This is a feature release:

* Users created lazily but not currently logged-in are now correctly detected as lazy users. To facilitate this, a ``LazyUser`` model is included. Note that existing code using ``is_lazy_user`` only on authenticated users will continue to work, as the old method of checking the ``backend`` attribute of the ``User`` object has been retained - it's faster to do that than a potentially unnecessary database query.

For those who use it, a South migration is provided to create the initial table. Data migration will be handled by South migrations from now on.

* The canonical import location of ``is_lazy_user`` has changed from within ``lazysignup.templatetags.lazysignup_tags`` to ``lazysignup.utils``. Existing code that imports from the old location will continue to work.

0.5.1-----

Bugfix release:

- Fix an issue where a lazy user would be misidentified as a non-lazy user

0.5.0-----

This version simplifies the implementation significantly by removing the requirement fora middleware. This is a backwards-incompatible change as the ``lazysignup.middleware``module no longer exists, and needs to be removed from your ``MIDDLEWARE_CLASSES`` list.

This change means that you can no longer disable the software by removing the middlewareclass from your configuration. You might want to do this temporarily in development, forexample, when testing that your views still work when an anonymous user is presented tothem (perhaps through the user agent blacklisting functionality).

To this end, support for a new settings has been added: ``ENABLE_LAZYSIGNUP``. It's setto True by default. Setting it to False will both prevent automatic login andautomatic user creation.

The ``allow_lazy_user`` decorator no longer has to be first in the decorator list. Thanksto Jauco Noordzij for pointing this out initially.

There is now also an ``is_lazy_user`` template filter, which will return True if thecurrent user is an automatically created user. It will return False for users who areanonymous, or were authenticated by some other means. Thanks again to Jauco Noordzijfor the idea for this feature.

Note that the ``is_lazy_user`` filter (which you can also just import and usedirectly in your view code) is the preferred way of checking for an automaticallycreated user. ``has_usable_password`` will continue to return False for such users,but is no longer the canonical way to identify them. Users authenticated withother authentication backends (for example, LDAP backends) may return False when``has_usable_password`` is called.

0.4.0-----

This version fixes a number of issues, adds new features and has backwards-incompatible changes:

- Fix a RST issue in README - Fix an issue where a POST to the convert view would break if the user was anonymous. The convert view now redirects to the LOGIN_URL by default, parameterised in the view.

New features:

- It is now easier to customise the process of converting a lazy user into a real user. Previous versions allowed a custom form to be passed to the ``convert`` view, but the code always expected a ``username`` and ``password1`` field to get credentials from to log the user in. Now, a new ``get_credentials()`` method is called on the form to obtain these credentials. - The tests module now includes a ``no_lazysignup`` decorator that you can apply to a method on your test case, which removes the lazy signup middleware for the duration of that test only. This is useful for testing what happens when a view that is marked with with the ``allow_lazy_user`` decorator ends up with an anonymous user (most commonly, when a search engine visits).

Backwards-incompatible changes:

- Generated usernames are now based on the session key, rather than actually being the session key. This is to avoid a potential security issue where an app might simply display a username, giving away a significant part of the user's session key. The username is now generated from a SHA1 hash of the session key. This change means that existing generated users will become invalid.

0.3.0-----

This version introduces a backwards-incompatible changes, renaming the ``@allow_lazy``decorator to ``@allow_lazy_user``. This is to avoid confusion with the decorator ofthe same name in ``django.utils.functional``.

0.2.0-----

This version fixes a number of issues:

- Correct a duplicated test - Fix a bug where a new user would not be created if they already had a session key.

It also introduces a new feature, user agent blacklisting. This aims toprevent explosive growth in the number of users created by search engines,etc. This feature is still in test, so patches and feedback welcome. Note thatthis introduces a backwards-incompatibly behaviour. Prior to this release,it was safe to assume that all views marked with the ``@allow_lazy`` decoratorwould receive an authenticated user. This is now no longer the case.

See the README.rst file for more information.

0.1.2-----

* Compatibility fixes for Django <1.2* The convert view is now itself lazy