If force_avatar_update is passed in sso attributes it errors on
force_avatar_update.to_i. The SingleSignOn class forces avatar_force_update
to a boolean, so it should be treated as such.
If a user has a current avatar, and sso_overrides_avatar is true, but no avatar_url is
passed in the sso attributes, the current code errors, as it tries to parse a nil
as a URL. It seems to me valid that a third party system may not pass an avatar_url in
some cases (e.g. avatars may not be mandatory, so not all users may have them)
This might warrant a discussion about what should happen in this case; maybe the current
avatar in discourse should be removed? This branch merely stops the login process erroring.
Implemented by having Discourse download the image from the provided URL
and treating it as a custom upload.
Adds two more parameters to the SSO site’s response:
* `avatar_url` specifies the URL of the overriding avatar.
* `avatar_force_update` Discourse does not re-download avatars that
has already been download from the same URL. Setting this to true forces
Discourse to re-download the avatar in `avatar_url`
Note that both parameters are ignored if `sso_overrides_avatar` is set
to false.
add an external_username attribute for username from SSO payload
repair the field name in SingleSignOnRecord migration
move setting of external_username for sso to controller
add settings toggle to override username/email from SSO payload
fix changing of external username after override toggle
complete tests and logic for sso override
add some extra context to username override option
add external_email and external_name to single sign on record
add setting for name override from SSO payload
complete override with stored external_email and external_name
add missing checks to tests
remove an unneeded describe block
break up a monster method for single sign on
fixes for sso attribute override after failed tests
Robin Ward
Régis Hanol
Dan Singerman
Sam
Wilhansen Li
Akshay
Neil Lalonde
Louis Rose
Erick Guan
Stephen Birarda