- Python 94.4%
- HTML 4.5%
- JavaScript 0.9%
- Makefile 0.1%
|
Andre Borie
2bd5c3a5cc
fix(openid_connect): gracefully handle requests with invalid provider IDs
This PR fixes an issue where external requests to OIDC endpoints quoting an unknown provider ID would end up with an unhandled `SocialApp.DoesNotExist` exception. As this issue is triggerable from the outside via an invalid URL, I think it's fair to swallow the exception and respond with a generic 404 error. I have added a unit test to confirm the behavior. # Submitting Pull Requests ## General - [x] Make sure you use [semantic commit messages](https://seesparkbox.com/foundry/semantic_commit_messages). Examples: `"fix(google): Fixed foobar bug"`, `"feat(accounts): Added foobar feature"`. - [x] All Python code must formatted using Black, and clean from pep8 and isort issues. - [ ] JavaScript code should adhere to [StandardJS](https://standardjs.com). - [ ] If your changes are significant, please update `ChangeLog.rst`. - [ ] If your change is substantial, feel free to add yourself to `AUTHORS`. ## Provider Specifics In case you add a new provider: - [x] Make sure unit tests are available. - [ ] Add an entry of your provider in `test_settings.py::INSTALLED_APPS` and `docs/installation.rst::INSTALLED_APPS`. - [ ] Add documentation to `docs/providers/<provider name>.rst` and `docs/providers/index.rst` Provider Specifics toctree. - [ ] Add an entry to the list of supported providers over at `docs/overview.rst`. Reviewed-on: allauth/django-allauth#4220 Co-authored-by: Andre Borie <hi@rjevski.io> Co-committed-by: Andre Borie <hi@rjevski.io> |
||
|---|---|---|
| .gitea | chore: Pull request template | |
| .github | chore(ci): Add bandit security checks | |
| allauth | fix(openid_connect): gracefully handle requests with invalid provider IDs | |
| docs | fix(headless/spec): Documentation typ-o's | |
| examples | feat(headless): Serve OpenAPI specification | |
| tests | feat(headless): Serve OpenAPI specification | |
| .dir-locals.el | chore: Add standardjs to dev env | |
| .djlintrc | refactor(templates): Use {% element %} for socialaccount | |
| .editorconfig | feat(account): Separate template for changing email | |
| .envrc | chore(Makefile): Cleanup | |
| .gitignore | fix(socialaccount): Don't swallow indirect import errors | |
| .readthedocs.yaml | fix(docs): autodoc not rendering | |
| .woodpecker.yaml | chore(ci): Add bandit security checks | |
| AUTHORS | refactor(socialaccount): Uniform SocialAccount.to_str() | |
| ChangeLog.rst | docs: fix changelog date | |
| LICENSE | chore: Preparing release 0.45.0 | |
| Makefile | feat(headless): Serve OpenAPI specification | |
| manage.py | chore(manage): Pick up D_S_M from env, if set | |
| MANIFEST.in | fix(headless): Package the OpenAPI spec | |
| package-lock.json | chore: Add standardjs to dev env | |
| package.json | chore: Add standardjs to dev env | |
| pyproject.toml | fix(headless): Email verification by code & change email | |
| pytest.ini | tests: Move to tests.regular | |
| README.rst | chore: Move project URLs to Codeberg | |
| setup.cfg | chore: Minimum Django now points to last patch version | |
| setup.py |
refactor(setup): Move to setup.cfg
|
|
| shell.nix | chore(ci): Add bandit security checks | |
| tox.ini | fix(headless): yaml missing | |
Welcome to django-allauth!
ci pypi Coverage Status btc liberapay pystyle jsstyle editor i18n PyPI - Downloads View Django Demo View React SPA Demo
Integrated set of Django applications addressing authentication, registration, account management as well as 3rd party (social) account authentication.
- Home page
- Source code
- Issue Tracker
- Documentation
- Stack Overflow
- Demo
-
https://django.demo.allauth.org and https://react.demo.allauth.org
- Translations
Rationale
Most existing Django apps that address the problem of social authentication unfortunately focus only on one dimension - the social. Most developers end up integrating another app in order to support authentication flows that are locally generated.
This approach creates a development gap between local and social authentication flows. It has remained an issue in spite of numerous common scenarios that both require. For example, an email address passed along by an OpenID provider may not be verified. Therefore, prior to hooking up an OpenID account to a local account the email address must be verified. This essentially is one of many use cases that mandate email verification to be present in both worlds.
Integrating both is a humongous and tedious process. It is not as
simple as adding one social authentication app, and one local account
registration app to your INSTALLED_APPS list.
This inadequacy is the reason for this project's existence -- to offer a fully integrated authentication app that allows for both local and social authentication, with flows that just work, beautifully!
Features
- 🔑 Comprehensive account functionality
-
Supports multiple authentication schemes (e.g. login by user name, or by email), as well as multiple strategies for account verification (ranging from none to mandatory email verification).
- 👥 Social Login
-
Login using external identity providers, supporting any Open ID Connect compatible provider, many OAuth 1.0/2.0 providers, as well as custom protocols such as, for example, Telegram authentication.
- 💼 Enterprise ready
-
Supports SAML 2.0, which is often used in a B2B context.
- 🕵️ Battle-tested
-
The package has been out in the open since 2010. It is in use by many commercial companies whose business depends on it and has hence been subjected to various penetration testing attempts.
- ⏳Rate limiting
-
When you expose an authentication-enabled web service to the internet, it is important to be prepared for potential brute force attempts. Therefore, rate limiting is enabled out of the box.
- 🔒 Private
-
Many sites leak information. For example, on many sites you can check whether someone you know has an account by input their email address into the password forgotten form, or trying to signup with it. We offer account enumeration prevention, making it impossible to tell whether or not somebody already has an account.
- 🧩 Customizable
-
As a developer, you have the flexibility to customize the core functionality according to your specific requirements. By employing the adapter pattern, you can effortlessly introduce interventions at the desired points to deviate from the standard behavior. This level of customization empowers you to tailor the software to meet your unique needs and preferences.
- ⚙️ Configuration
-
The required consumer keys and secrets for interacting with Facebook, X (Twitter) and the likes can be configured using regular settings, or, can be configured in the database via the Django admin. Here, optional support for the Django sites framework is available, which is helpful for larger multi-domain projects, but also allows for easy switching between a development (localhost) and production setup without messing with your settings and database.
Commercial Support
Commercial support is available. If you find certain functionality missing, or require assistance on your project(s), please contact us: info@intenct.nl.