If a site setting has `shadowed_by_global: true` then, if
a `GlobalSetting` exists with the same name then that value
will be used instead. Additionally, the setting will be hidden.
This is useful in a multisite environment for private settings
such as API keys. You want to set it globally, yet not display
the key to customers.
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.
FIX: Don't require login to view post raw
FIX: Don't submit read-guidelines for anonymous users (causes
unnecessary 403 errors from ensure_logged_in)
FIX: Don't pass nil to an array serializer
- FIX: make sure we set a default name to a pasted image only on Chrome (the only browser that supports it)
- FIX: use ".json" extension to uploads endpoints since IE9 doesn't pass the correct header
- FIX: pass the CSRF token in a query parameter since IE9 doesn't pass it in the headers
- FIX: display error messages comming from the server when there is one over the default error message
- FIX: HACK around IE9 security issue when clicking a file input via JavaScript (use a label and set `visibility:hidden` on the input)
- FIX: hide the "cancel" upload on IE9 since it's not supported
- FIX: return "text/plain" content-type when uploading a file for IE9 in order to prevent it from displaying the save dialog
- FIX: check the maximum file size on the server 💥
- update jQuery File Upload Plugin to v. 5.42.2
- update JQuery IFram Transport Plugin to v. 1.8.5
- update jQuery UI Widget to v. 1.11.1
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.
This fixes a bug where the server would 500 if the only user fields
where optional ones, and the create_user call didn't provide any
values so that params[:user_fields] was nil.
Additionally, don't bother double-checked for required fields, since we
iterate over all fields and will catch any that are required and blank.
This security fix needs SSO to be configured, and the user has to go
through the entire auth process before being redirected to the wrong host so
it is probably lower priority for most installs.