Releases: indico/flask-multipass
Releases · indico/flask-multipass
v0.10
v0.9
- Include the username in the
identifierattribute of theNoSuchUserexception so applications can apply e.g. per-username rate limiting - Fail silently when there's no
objectSidfor an AD-style LDAP group
v0.8
- Reject
nextURLs containing linebreaks gracefully - Look for
logout_uriin top-level authlib provider config instead of theauthlib_argsdict (the latter is still checked as a fallback) - Include
id_token_hintin authlib logout URL - Add
logout_argssetting to authlib provider which allows removing some of the query string arguments that are included by default
v0.7
- Support multiple id fields in SAML identity provider
- Include
client_idin authlib logout URL since some OIDC providers mayrequire this - Allow setting timeout for authlib token requests (default: 10 seconds)
- Add new
MULTIPASS_HIDE_NO_SUCH_USERconfig setting to convertNoSuchUserexceptions toInvalidCredentialsto avoid disclosing whether a username is valid - Include the username in the
identifierattribute of theInvalidCredentialsexception so applications can apply e.g. per-username rate limiting
v0.6
- Drop support for Python 3.8 (3.8 is EOL since Oct 2024)
- Remove upper version pins of dependencies
- Support friendly names for SAML assertions (set
'saml_friendly_names': Truein the auth provider settings) - Include more verbose authentication data in
IdentityRetrievalFailedexception details
v0.5.6
- Reject invalid
nextURLs with backslashes that could be used to trick browsers into redirecting to an otherwise disallowed host when doing client-side redirects
v0.5.5
- Ensure only valid schemas (http and https) can be used when validating the
nextURL - Deprecate the
flask_multipass.__version__attribute
v0.5.4
- Skip LDAP users that do not have the specified
uidattribute set instead of failing with an error
v0.5.3
- Skip LDAP group members that do not have the specified
uidattribute set instead of failing with an error
v0.5.2
- Add
ldap_or_authinfoidentity provider which behaves exactly like theldapprovider, but if the user cannot be found in LDAP, it falls back to the data from the auth provider (typically Shibboleth)