| Name | django-otp JSON |
| Version |
1.5.2
JSON |
| download |
| home_page | None |
| Summary | A pluggable framework for adding two-factor authentication to Django using one-time passwords. |
| upload_time | 2024-08-18 22:47:07 |
| maintainer | None |
| docs_url | None |
| author | None |
| requires_python | >=3.7 |
| license | None |
| keywords |
|
| VCS |
 |
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
|
.. vim: tw=80 lbr
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.
Well-formed issues and pull requests are welcome, but please see
CONTRIBUTING.rst first. General questions and ideas should be directed to the
Discussions section; issues should be reserved for confirmed bugs.
.. end-of-doc-intro
Development
-----------
This project is built and managed with `hatch`_. If you don't have hatch, I
recommend installing it with `pipx`_: ``pipx install hatch``.
``pyproject.toml`` defines several useful scripts for development and testing.
The default environment includes all dev and test dependencies for quickly
running tests. The ``test`` environment defines the test matrix for running the
full validation suite. Everything is executed in the context of the Django
project in test/test\_project.
As a quick primer, hatch scripts can be run with ``hatch run [<env>:]<script>``.
To run linters and tests in the default environment, just run
``hatch run check``. This should run tests with your default Python version and
the latest Django. Other scripts include:
* **manage**: Run a management command via the test project. This can be used to
generate migrations.
* **lint**: Run all linters.
* **fix**: Run all fixers to address linting issues. This may not fix every
issue reported by lint.
* **test**: Run all tests.
* **check**: Run linters and tests.
* **warn**: Run tests with all warnings enabled. This is especially useful for
seeing deprecation warnings in new versions of Django.
* **cov**: Run tests and print a code coverage report.
To run the full test matrix, run ``hatch run test:run``. You will need multiple
specific Python versions installed for this.
You can clean up the hatch environments with ``hatch env prune``, for example to
force dependency updates.
The project under ``test`` can be run as a simple interactive test environment.
Run ``hatch run manage runserver`` and open it in a browser. This has an
implementation of the login form and views with different combinations of
decorators, which you can experiment with or use to test changes.
Configuration
~~~~~~~~~~~~~
By default, the test project uses SQLite. Because SQLite doesn't support row
locking, some concurrency tests will be skipped. To test against PostgreSQL, you
can add a local configuration file that points to your database.
Configuration is taken from TOML files stored under ``test/config``. A config
file named ``env-<env-name>.toml`` will be automatically applied when running
inside a matching hatch environment. For example, ``env-default.toml`` applies
to the default development environment and ``env-test.toml`` applies to the test
matrix environments.
With a wide-open PostgreSQL install, an ``env-test.toml`` might look like this:
.. code-block:: toml
[database]
ENGINE = "django.db.backends.postgresql"
NAME = "django-otp"
USER = "postgres"
For development, the config file can also be used to inject Django apps and
middleware, or to override arbitrary Django settings. See
``test/config/sample.toml`` for a full description.
You can also force a specific config file by setting the environment variable
``DJANGO_OTP_CONFIG`` to a path.
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.
.. _hatch: https://hatch.pypa.io/
.. _pipx: https://pypa.github.io/pipx/
Raw data
{
"_id": null,
"home_page": null,
"name": "django-otp",
"maintainer": null,
"docs_url": null,
"requires_python": ">=3.7",
"maintainer_email": null,
"keywords": null,
"author": null,
"author_email": "Peter Sagerson <psagers@ignorare.net>",
"download_url": "https://files.pythonhosted.org/packages/39/d9/d9022aa7481895ee0d54e82525a123360e1bc0fcb25186bd27a2462e4c8a/django_otp-1.5.2.tar.gz",
"platform": null,
"description": ".. vim: tw=80 lbr\n\ndjango-otp\n==========\n\n.. image:: https://img.shields.io/pypi/v/django-otp?color=blue\n :target: https://pypi.org/project/django-otp/\n :alt: PyPI\n.. image:: https://img.shields.io/readthedocs/django-otp-official\n :target: https://django-otp-official.readthedocs.io/\n :alt: Documentation\n.. image:: https://img.shields.io/badge/github-django--otp-green\n :target: https://github.com/django-otp/django-otp\n :alt: Source\n\nThis project makes it easy to add support for `one-time passwords\n<http://en.wikipedia.org/wiki/One-time_password>`_ (OTPs) to Django. It can be\nintegrated at various levels, depending on how much customization is required.\nIt integrates with ``django.contrib.auth``, although it is not a Django\nauthentication backend. The primary target is developers wishing to incorporate\nOTPs into their Django projects as a form of `two-factor authentication\n<http://en.wikipedia.org/wiki/Two-factor_authentication>`_.\n\nSeveral simple OTP plugins are included and more are available separately. This\npackage also includes an implementation of OATH `HOTP\n<http://tools.ietf.org/html/rfc4226>`_ and `TOTP\n<http://tools.ietf.org/html/rfc6238>`_ for convenience, as these are standard\nOTP algorithms used by multiple plugins.\n\nIf you're looking for a higher-level or more opinionated solution, you might be\ninterested in `django-two-factor-auth\n<https://github.com/Bouke/django-two-factor-auth>`_.\n\nStatus\n------\n\nThis project is stable and maintained, but is no longer actively used by the\nauthor and is not seeing much ongoing investment.\n\nWell-formed issues and pull requests are welcome, but please see\nCONTRIBUTING.rst first. General questions and ideas should be directed to the\nDiscussions section; issues should be reserved for confirmed bugs.\n\n.. end-of-doc-intro\n\n\nDevelopment\n-----------\n\nThis project is built and managed with `hatch`_. If you don't have hatch, I\nrecommend installing it with `pipx`_: ``pipx install hatch``.\n\n``pyproject.toml`` defines several useful scripts for development and testing.\nThe default environment includes all dev and test dependencies for quickly\nrunning tests. The ``test`` environment defines the test matrix for running the\nfull validation suite. Everything is executed in the context of the Django\nproject in test/test\\_project.\n\nAs a quick primer, hatch scripts can be run with ``hatch run [<env>:]<script>``.\nTo run linters and tests in the default environment, just run\n``hatch run check``. This should run tests with your default Python version and\nthe latest Django. Other scripts include:\n\n* **manage**: Run a management command via the test project. This can be used to\n generate migrations.\n* **lint**: Run all linters.\n* **fix**: Run all fixers to address linting issues. This may not fix every\n issue reported by lint.\n* **test**: Run all tests.\n* **check**: Run linters and tests.\n* **warn**: Run tests with all warnings enabled. This is especially useful for\n seeing deprecation warnings in new versions of Django.\n* **cov**: Run tests and print a code coverage report.\n\nTo run the full test matrix, run ``hatch run test:run``. You will need multiple\nspecific Python versions installed for this.\n\nYou can clean up the hatch environments with ``hatch env prune``, for example to\nforce dependency updates.\n\nThe project under ``test`` can be run as a simple interactive test environment.\nRun ``hatch run manage runserver`` and open it in a browser. This has an\nimplementation of the login form and views with different combinations of\ndecorators, which you can experiment with or use to test changes.\n\nConfiguration\n~~~~~~~~~~~~~\n\nBy default, the test project uses SQLite. Because SQLite doesn't support row\nlocking, some concurrency tests will be skipped. To test against PostgreSQL, you\ncan add a local configuration file that points to your database.\n\nConfiguration is taken from TOML files stored under ``test/config``. A config\nfile named ``env-<env-name>.toml`` will be automatically applied when running\ninside a matching hatch environment. For example, ``env-default.toml`` applies\nto the default development environment and ``env-test.toml`` applies to the test\nmatrix environments.\n\nWith a wide-open PostgreSQL install, an ``env-test.toml`` might look like this:\n\n.. code-block:: toml\n\n [database]\n ENGINE = \"django.db.backends.postgresql\"\n NAME = \"django-otp\"\n USER = \"postgres\"\n\nFor development, the config file can also be used to inject Django apps and\nmiddleware, or to override arbitrary Django settings. See\n``test/config/sample.toml`` for a full description.\n\nYou can also force a specific config file by setting the environment variable\n``DJANGO_OTP_CONFIG`` to a path.\n\n\nThe Future\n----------\n\nOnce upon a time, everything was usernames and passwords. Or even in the case of\nother authentication mechanisms, a user was either authenticated or not\n(anonymous in Django's terminology). Then there was two-factor authentication,\nwhich could simply be an implementation detail in a binary authentication state,\nbut could also imply levels or degrees of authentication.\n\nThese days, it's increasingly common to see sites with more nuanced\nauthentication state. A site might remember who you are forever\u2014so you're not\nanonymous\u2014but if you try to do anything private, you have to re-authenticate.\nYou may be able to choose from among all of the authentication mechanisms you\nhave configured, or only from some of them. Specific mechanisms may be required\nfor specific actions, such as using your U2F device to access your U2F settings.\n\nIn short, the world seems to be moving beyond the assumptions that originally\ninformed Django's essential authentication design. If I were still investing in\nDjango generally, I would probably start a new multi-factor authentication\nproject that would reflect these changes. It would incorporate the idea that a\nuser may be authenticated by various combinations of mechanisms at any time and\nthat different combinations may be required to satisfy diverse authorization\nrequirements across the site. It would most likely try to disentangle\nauthentication persistence from sessions, at least to some extent. Many sites\nwould not require all of this flexibility, but it would open up possibilities\nfor better experiences by not asking users for more than we require at any\npoint.\n\nIf anyone has a mind to take on a project like this, I'd be happy to offer\nwhatever advice or lessons learned that I can.\n\n\n.. _hatch: https://hatch.pypa.io/\n.. _pipx: https://pypa.github.io/pipx/\n",
"bugtrack_url": null,
"license": null,
"summary": "A pluggable framework for adding two-factor authentication to Django using one-time passwords.",
"version": "1.5.2",
"project_urls": {
"Documentation": "https://django-otp-official.readthedocs.io/",
"Homepage": "https://github.com/django-otp/django-otp"
},
"split_keywords": [],
"urls": [
{
"comment_text": null,
"digests": {
"blake2b_256": "e34617f4a4ca4f5466f0798fccadc632771407c968e0ad90f9ceb69ab737379a",
"md5": "c2eb0285fa2759dc3c07bbb4de347cf0",
"sha256": "931a4f46f0ec10cab4d25ac8b7dfd6344538320b0489716cabb0da3108dabd75"
},
"downloads": -1,
"filename": "django_otp-1.5.2-py3-none-any.whl",
"has_sig": false,
"md5_digest": "c2eb0285fa2759dc3c07bbb4de347cf0",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": ">=3.7",
"size": 82063,
"upload_time": "2024-08-18T22:47:05",
"upload_time_iso_8601": "2024-08-18T22:47:05.873685Z",
"url": "https://files.pythonhosted.org/packages/e3/46/17f4a4ca4f5466f0798fccadc632771407c968e0ad90f9ceb69ab737379a/django_otp-1.5.2-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": null,
"digests": {
"blake2b_256": "39d9d9022aa7481895ee0d54e82525a123360e1bc0fcb25186bd27a2462e4c8a",
"md5": "5fb6b0fe0372e0c833f5e553c79652ef",
"sha256": "fc6d13025eb659030684728ab55b9343e06069c62a17d5f3be2649d8ee314f0f"
},
"downloads": -1,
"filename": "django_otp-1.5.2.tar.gz",
"has_sig": false,
"md5_digest": "5fb6b0fe0372e0c833f5e553c79652ef",
"packagetype": "sdist",
"python_version": "source",
"requires_python": ">=3.7",
"size": 73778,
"upload_time": "2024-08-18T22:47:07",
"upload_time_iso_8601": "2024-08-18T22:47:07.587090Z",
"url": "https://files.pythonhosted.org/packages/39/d9/d9022aa7481895ee0d54e82525a123360e1bc0fcb25186bd27a2462e4c8a/django_otp-1.5.2.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-08-18 22:47:07",
"github": true,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"github_user": "django-otp",
"github_project": "django-otp",
"travis_ci": false,
"coveralls": true,
"github_actions": true,
"lcname": "django-otp"
}
