Metadata-Version: 2.1
Name: django-otp
Version: 1.1.0
Summary: A pluggable framework for adding two-factor authentication to Django using one-time passwords.
Home-page: https://github.com/django-otp/django-otp
Author: Peter Sagerson
Author-email: psagers@ignorare.net
License: BSD
Project-URL: Documentation, https://django-otp-official.readthedocs.io/
Project-URL: Source, https://github.com/django-otp/django-otp
Description: django-otp
        ==========
        
        .. image:: https://img.shields.io/pypi/v/django-otp?color=blue
           :target: https://pypi.org/project/django-otp/
           :alt: PyPI
        .. image:: https://img.shields.io/readthedocs/django-otp-official
           :target: https://django-otp-official.readthedocs.io/
           :alt: Documentation
        .. image:: https://img.shields.io/badge/github-django--otp-green
           :target: https://github.com/django-otp/django-otp
           :alt: Source
        
        This project makes it easy to add support for `one-time passwords
        <http://en.wikipedia.org/wiki/One-time_password>`_ (OTPs) to Django. It can be
        integrated at various levels, depending on how much customization is required.
        It integrates with ``django.contrib.auth``, although it is not a Django
        authentication backend. The primary target is developers wishing to incorporate
        OTPs into their Django projects as a form of `two-factor authentication
        <http://en.wikipedia.org/wiki/Two-factor_authentication>`_.
        
        Several simple OTP plugins are included and more are available separately. This
        package also includes an implementation of OATH `HOTP
        <http://tools.ietf.org/html/rfc4226>`_ and `TOTP
        <http://tools.ietf.org/html/rfc6238>`_ for convenience, as these are standard
        OTP algorithms used by multiple plugins.
        
        If you're looking for a higher-level or more opinionated solution, you might be
        interested in `django-two-factor-auth
        <https://github.com/Bouke/django-two-factor-auth>`_.
        
        Status
        ------
        
        This project is stable and maintained, but is no longer actively used by the
        author and is not seeing much ongoing investment. Anyone interested in taking
        over aspects of the project should `contact me <https://github.com/psagers>`_.
        
        Well-formed issues and pull requests are welcome, but please see the
        Contributing section of the README first.
        
        .. end-of-doc-intro
        
        
        The Future
        ----------
        
        Once upon a time, everything was usernames and passwords. Or even in the case of
        other authentication mechanisms, a user was either authenticated or not
        (anonymous in Django's terminology). Then there was two-factor authentication,
        which could simply be an implementation detail in a binary authentication state,
        but could also imply levels or degrees of authentication.
        
        These days, it's increasingly common to see sites with more nuanced
        authentication state. A site might remember who you are forever—so you're not
        anonymous—but if you try to do anything private, you have to re-authenticate.
        You may be able to choose from among all of the authentication mechanisms you
        have configured, or only from some of them. Specific mechanisms may be required
        for specific actions, such as using your U2F device to access your U2F settings.
        
        In short, the world seems to be moving beyond the assumptions that originally
        informed Django's essential authentication design. If I were still investing in
        Django generally, I would probably start a new multi-factor authentication
        project that would reflect these changes. It would incorporate the idea that a
        user may be authenticated by various combinations of mechanisms at any time and
        that different combinations may be required to satisfy diverse authorization
        requirements across the site. It would most likely try to disentangle
        authentication persistence from sessions, at least to some extent. Many sites
        would not require all of this flexibility, but it would open up possibilities
        for better experiences by not asking users for more than we require at any
        point.
        
        If anyone has a mind to take on a project like this, I'd be happy to offer
        whatever advice or lessons learned that I can.
        
        
        Development
        -----------
        
        Development dependencies are defined in the Pipfile; use `pipenv`_ to set up a
        suitable shell.
        
        The tests in tox.ini cover a representative sample of supported Python and
        Django versions, as well as running `flake8`_ and `isort`_ for linting and style
        consistency. Please run `tox` before checking in and sending a pull request.
        
        
        Contributing
        ------------
        
        As mentioned above, this project is stable and mature. Issues and pull requests
        are welcome for important bugs and improvements. For non-trivial changes, it's
        often a good idea to start by opening an issue to track the need for a change
        and then optionally open a pull request with a proposed resolution. Issues and
        pull requests should also be focused on a single thing. Pull requests that
        bundle together a bunch of loosely related commits are unlikely to go anywhere.
        
        Another good rule of thumb—for any project, but especially a mature one—is to
        keep changes as simple as possible. In particular, there should be a high bar
        for adding new dependencies. Although it can't be ruled out, it seems highly
        unlikely that a new runtime dependency will ever be added. New testing
        dependencies are more likely, but only if there's no other way to address an
        important need.
        
        If there's a development tool that you'd like to use with this project, the
        first step is to try to update config files (setup.cfg or similar) to integrate
        the tool with the existing code. A bit of configuration glue for popular tools
        should always be safe. If that's not possible, we can consider modifying the
        code to be compatible with a broader range of tools (without breaking any
        existing compatibilities). Only as a last resort would a new testing or
        development tool be incorporated into the project as a dependency.
        
        It's also good to remember that writing the code is typically the least part of
        the work. This is true for software development in general, but especially a
        small stable project like this. The bulk of the work is in `understanding the
        problem <http://www.youtube.com/watch?v=f84n5oFoZBc>`_, determining the desired
        attributes of a solution, researching and evaluating alternatives, writing
        documentation, designing a testing strategy, etc. Writing the code itself tends
        to be a minor matter that emerges from that process.
        
        
        .. _pipenv: https://pipenv.readthedocs.io/en/latest/
        .. _flake8: https://pypi.org/project/flake8/
        .. _isort: https://pypi.org/project/isort/
        
Platform: UNKNOWN
Classifier: Development Status :: 5 - Production/Stable
Classifier: Framework :: Django
Classifier: Intended Audience :: Developers
Classifier: License :: OSI Approved :: BSD License
Classifier: Programming Language :: Python :: 3
Classifier: Programming Language :: Python :: 3 :: Only
Classifier: Topic :: Security
Classifier: Topic :: Software Development :: Libraries :: Python Modules
Provides-Extra: qrcode
