* Make omniauth controller specs more robust by using shared examples for all authentication providers in controller spec. – Still passing. Yay!
* Return "casuser", instead of "casuser@" when no cas_domainname is configured.
* If no cas_domainname is configured, the CAS authentication would return "casuser@" for the users email field, because it tried to assume the email adress of the CAS user by it's username + cas_domainname.
Now it just returns the username instead of adding an "@" if cas_domainname is not configured.
This especially makes sense on CAS setups where the username equals the users email adress.
The old behaviour, if cas_domainname is configured, was not changed.
* Fetch the email from CAS attributes if provided
If the cas:authenticationSuccess (handled via omniauth-cas) response gives us an email use that.
If not, behave as before (username or username@cas_domainname).
* Fetch the (full) name from CAS attributes if provided
If the CAS response by omniauth provides a [:info][:name] field, prefer this over the uid, because we want the name to be a "Full Name", instead of just a "shortname"
- minor refactoring of actions 'category' and 'category_feed'
- fix defect in 'category' where check was for literal
string 'uncategorized' instead of SiteSetting.uncategorized_name
- major refactoring on defined topic actions
We are now explicitly whitelisting all parameters for Post creation. A nice side-effect is that it cleans up the #create action in PostsController. We can now trust that all parameters entering PostCreator are of a safe scalar type.
When 'must approve users' in enabled, we don't want to send an
activation email to users after they sign up. Instead, we will show them
'waiting approval' and not take an action until their account is
approved by an admin.
All models are now using ActiveModel::ForbiddenAttributesProtection, which shifts the responsibility for parameter whitelisting for mass-assignments from the model to the controller. attr_accessible has been disabled and removed as this functionality replaces that.
The require_parameters method in the ApplicationController has been removed in favor of strong_parameters' #require method.
It is important to note that there is still some refactoring required to get all parameters to pass through #require and #permit so that we can guarantee that parameter values are scalar. Currently strong_parameters, in most cases, is only being utilized to require parameters and to whitelist the few places that do mass-assignments.
When 'invite only' is enabled, there's no way for a user to create an
account unless they try and sneak in by POSTing to /users/. We will
silently fail if this happens.
The topic_id param is now required using strong_parameters' #require method. If the parameter is missing ActionController::ParameterMissing will be raised instead of Discourse::InvalidParameters.
PostActionsController now uses strong_parameters' #require to require certain parameters. ActionController::ParameterMissing is now thrown when a reqired parameter is missing, rather than Discourse::InvalidParameters.
The email parameter is now required using strong parameters and will throw ActionController::ParameterMissing if it is missing. If the email address is incorrect or invalid, Discourse::InvalidParameters will still be thrown.
