* 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"
This fixes all known issues when connecting to discourse over IPv6.
This table has no primary key, so the migration is done with update_all,
for each ip address in the views table. Since this table can potentially
grow quite large, this process might take a long time. I don't know any
way around this, though.
This migration uses a SQL command to populate the new field from the old
one, so as not to rely on the View model class, which should keep the
migration from failing if that class is modified in the future.
When accessed over IPv6, the ip address of the user is a 128-bit number,
too big for PostgreSQL's bigint data type. Since PostgresSQL has the
built-in inet type, which handles both IPv4 and IPv6 addresses, we
should use that instead. Where this is done elsewhere in the codebase,
the column is called ip_address, so we should follow that convention as
well.
This migration uses a SQL command to populate the new field from the old
one, so as not to rely on the TopicLinkClick model class, which should
keep the migration from failing if that class is modified in the future.
