Releases: indico/flask-multipass
Releases · indico/flask-multipass
v0.10
v0.9
- Include the username in the
identifier
attribute of theNoSuchUser
exception so applications can apply e.g. per-username rate limiting - Fail silently when there's no
objectSid
for an AD-style LDAP group
v0.8
- Reject
next
URLs containing linebreaks gracefully - Look for
logout_uri
in top-level authlib provider config instead of theauthlib_args
dict (the latter is still checked as a fallback) - Include
id_token_hint
in authlib logout URL - Add
logout_args
setting 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_id
in 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_USER
config setting to convertNoSuchUser
exceptions toInvalidCredentials
to avoid disclosing whether a username is valid - Include the username in the
identifier
attribute of theInvalidCredentials
exception 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': True
in the auth provider settings) - Include more verbose authentication data in
IdentityRetrievalFailed
exception details
v0.5.6
- Reject invalid
next
URLs 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
next
URL - Deprecate the
flask_multipass.__version__
attribute
v0.5.4
- Skip LDAP users that do not have the specified
uid
attribute set instead of failing with an error
v0.5.3
- Skip LDAP group members that do not have the specified
uid
attribute set instead of failing with an error
v0.5.2
- Add
ldap_or_authinfo
identity provider which behaves exactly like theldap
provider, but if the user cannot be found in LDAP, it falls back to the data from the auth provider (typically Shibboleth)