Fix preference and (add) enforcing option for canonical email
- Add enforce_canonical_email in OpenIDRPConfig model
- Add enforce_canonical_email migration
- Moves `get_canonical_email` and `is_canonical_email` to utils module.
Main reason for this is that this is where other functions like
`is_canonicalish_email` and `is_long_form_email` recide that are used
for OpenID authentication.
Also removes `is_long_form_email` and `is_canonicalish_email` from the
processors module since they are identical to the ones in utils module
- Adds new `get_suitable_email` function to take care of what email should
be returned to OpenID transactions. It calls `get_canonical_email`
function which is somewhat similar in behavior to what
`_get_suitable_email` does in views/server module. Also makes use of the
introduced `enforce_canonical_email`. Main reason for this is to
properly serve the `prefer_canonical_email` setting on OpenIDRPConfig
model. Now if the `prefer_canonical_email` is set (and not the enforcing
one), if the user doesn't have a canonical email, we will simply return
the currently preferred one. Whereas until now, in such scenarios we
were returning `None` instead.
- Replaces the `_get_suitable_email` function with the new one in utils
module which fixes and issue with the `prefer_canonical_email` setting
and also makes use of the `enforce_canonical_email` setting
- Switches to using the `get_suitable_email` function instead of the
`get_canonical_email` one with the caveat that it uses the fixed kwarg
`enforce_canonical` as True. This opens the opportunity to add more
options (such as "prefer_canonical_email") in SAML as well
- Fixes SN-2008
The JAAS team is retiring the production JAAS service, and would like to
send their users a warning in advance of the cut-off date so the users
aren't completely surprised to find they suddenly don't have access to
the service. Unfortunately, the team only has the SSO usernames of their
users, and need a way to translate from SSO usernames to email
addresses.
This change introduces a simple management command that takes the
usernames to be mapped, and maps them to email addresses. The management
command is intended to be ran from one of the sso-app units in
production, and can be ran like this:
where "jaas" is the full path to a file containing a list of usernames,
one on each line, and "emails" is the name of the output file to contain
the associated email addresses. Output is formatted as a CSV for easy
consumption by other software.
The JAAS team is retiring the production JAAS service, and would like to
send their users a warning in advance of the cut-off date so the users
aren't completely surprised to find they suddenly don't have access to
the service. Unfortunately, the team only has the SSO usernames of their
users, and need a way to translate from SSO usernames to email
addresses.
This change introduces a simple management command that takes the
usernames to be mapped, and maps them to email addresses. The management
command is intended to be ran from one of the sso-app units in
production, and can be ran like this:
where "jaas" is the full path to a file containing a list of usernames,
one on each line, and "emails" is the name of the output file to contain
the associated email addresses. Output is formatted as a CSV for easy
consumption by other software.
Switches to using the `get_suitable_email` function instead of the
`get_canonical_email` one with the caveat that it uses the fixed kwarg
`enforce_canonical` as True. This opens the opportunity to add more
options (such as "prefer_canonical_email") in SAML as well
Replace `_get_suitable_email` with the one in utils.py
Replaces the `_get_suitable_email` function with the new one in utils
module which fixes and issue with the `prefer_canonical_email` setting
and also makes use of the `enforce_canonical_email` setting
Adds new `get_suitable_email` function to take care of what email should
be returned to OpenID transactions. It calls `get_canonical_email`
function which is somewhat similar in behavior to what
`_get_suitable_email` does in views/server module. Also makes use of the
introduced `enforce_canonical_email`. Main reason for this is to
properly serve the `prefer_canonical_email` setting on OpenIDRPConfig
model. Now if the `prefer_canonical_email` is set (and not the enforcing
one), if the user doesn't have a canonical email, we will simply return
the currently preferred one. Whereas until now, in such scenarios we
were returning `None` instead.
