Re: [Unity-idm-discuss] prohibit whitespace characters for some attributes

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

Hi Sander,

W dniu 30.08.2022 o 09:12, Sander Apweiler pisze:
> Good morning Krzysztof,
> maybe you do not need a url attribute type. But parsing the input by
> the java trim function removes all whitespace in the beginning and at
> the end. This should also remove linebreak characters. This might be
> useful for all attributes. What do you think?

I'm afraid not. First of all range of use cases of string attributes is 
wide. We can not just start trimming all whitespaces, aven leading or 
trailing, may break many setups.

Feature to trim whitespaces from strings (as an optional setting in 
attribute type definition) can be considered. Anyway proper support for 
URLs is still needed. Whitespaces are one edge case, what about other 
mistakes in syntax? So I'm afraid we do need the extra type anyway.

Best,
Krzysztof



> Best regards,
> Sander
>
> On Mon, 2022-08-29 at 13:15 +0200, Krzysztof Benedyczak wrote:
>> Hi Sander,
>>
>> W dniu 25.08.2022 o 15:13, Sander Apweiler pisze:
>>> Hi Krzystzof,
>>> after I had a longer debug session with an administrator of a
>>> service
>>> who said there where a problem in unity, I was able to show him,
>>> that
>>> he created a wrong config. He entered in the OAuth return URL a
>>> linebreak.
>>>
>>> To avoid such problems, would it make sense to prohibit whitespace
>>> characters to some attributes like return URL or email addresses? A
>>> valid value never contains whitespace character.
>> Yes, this situation unfortunately can happen. It is because we don't
>> have a dedicated attribute value type for URLs (or URIs). And so
>> OAuth
>> client's return URL is stored in a plain string attribute.
>>
>> We were talking about that few times, but never approached that as we
>> are bit afraid of the migration: it may happen that current values
>> are
>> not parsable as URL ->  what then? Anyway as this was raised also on
>> community side, not only randomly internally, I'm opening a ticket to
>> cover that: introduce URL attribute value type, with proper
>> validation,
>> and migrate all system attributes to that type. Migration details
>> TBD.
>>
>>
>> In the case of emails this problem should not exist: we have a
>> dedicated
>> type for that, so as long as verifiableEmail type is used in
>> attribute
>> intended to store email, any invalid string should not be allowed.
>>
>> Best,
>> Krzysztof
>>