Re: [Unity-idm-discuss] Changed behaviour of translation profile configuration

[Krzysztof B. <kb...@un...>]

Hi Sander,

W dniu 11.05.2020 o 12:40, Sander Apweiler pisze:
> Dear Krzysztof,
>
> we updated last week from unity 2.8.2 to unity 3.2.2. After this update
> we got an issue with one of our connected IdPs.
>
> We had, which was an error on our site, configured the authenticator to
> used the translation profile "marineID" but created the translation
> profile "MarineID" within unity GUI. This mismatch worked fine until
> unity 2.8.2. and it seems that this configuration was case-insensitive.
>
> After the update we got an ticket that the login is not working and we
> started to investigate. After the error about unknown translation
> profile "marineID" we found the problem quite fast and changed the
> configuration from "marineID" into "MarineID" and reloaded the
> authenticator. Sadly the problem and error message kept the same and we
> decided to restart unity (load config from files instead of database)
> but the problem and error was still the same.
>
> Only changing the configuration and translation profile into "marineID"
> solved the issue. Because renaming a translation profile in the GUI
> (does not yes exists as file) and having two files with the same name
> (one starting with a capital, one with a lower letter) is not possible
> we had to copy the old one, remove it, and copy the copy to the old one
> with lower name.
>
> Was it intended to make the translation profile matching between
> configuration and existing profiles case sensitive? Was it intended
> that the translation profiles need to start with a small letter?
>
> In case both was intended can you please update the documentation to
> hint to that fact that translation profiles must start with lower
> letters and can you highlight such changes where you switch from
> (probably unwanted) case-insensitive to case-sensitiv configurations?
>
Well, in general all those identifiers always should be treated as case 
sensitive, both in 3.2 and 2.8 and before.

It can happen, though, and we hit it multiple times here too, that 
case-insensitive DB collation setting may allow for using different 
cases, which are still working fine. Maybe this was a case? It is 
especially hard when collation changes between different DBs, e.g. after 
migration.

Also I guess there was some additional issue with update of 
configuration, but I'm not able to decipher what exactly happened.

Cheers,
Krzysztof