Re: [pve-devel] [PATCH access-control] fix #5136: ldap: Decode non-ASCII characters in attributes

[Wolfgang Bumiller <w.bumiller@proxmox.com>]

On Wed, Dec 20, 2023 at 03:37:03PM +0100, Filip Schauer wrote:
> Decode non-ASCII character when syncing user attributes, since those

decode *how*?

> will be encoded later on. Without this fix the attributes where encoded
> twice, resulting in cases such as 'ü' turning into 'ü'.
> 
> Signed-off-by: Filip Schauer <f.schauer@proxmox.com>
> ---
>  src/PVE/Auth/LDAP.pm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/PVE/Auth/LDAP.pm b/src/PVE/Auth/LDAP.pm
> index b958f2b..5e7a30c 100755
> --- a/src/PVE/Auth/LDAP.pm
> +++ b/src/PVE/Auth/LDAP.pm
> @@ -301,7 +301,7 @@ sub get_users {
>  
>  	foreach my $attr (keys %$user_attributes) {
>  	    if (my $ours = $ldap_attribute_map->{$attr}) {
> -		$ret->{$username}->{$ours} = $user_attributes->{$attr}->[0];
> +		$ret->{$username}->{$ours} = PVE::Tools::decode_text($user_attributes->{$attr}->[0]);

This does 2 things: URI unescaping and utf-8 decoding.
Does the former make sense?

Given that 'decode_text' is a way too generic name in a module with yet
another way too generic name "tools", I'd argue against its use in
general and would prefer to call the *actual* decode function right
there so you can see what's going on.

>  	    }
>  	}
>  
> -- 
> 2.39.2