Item13630: Foswiki crashes when logging in with an underscore in the login name

We are experiencing the same problem as explained in Support.Question1646

A Foswiki 2.0.1, with LdapContrib, crashes with a login like name_c2.

The encoding of the store as for Ldap is iso-8859-1

..
$Foswiki::cfg{Ldap}{CharSet} = 'iso-8859-1'
..
$Foswiki::cfg{Store}{Encoding} = 'iso-8859-1';
..

I got the wiki running with the following hack:

/lib/Foswiki/Contrib/LdapContrib.pm

sub isGroup {
  my ($this, $wikiName, $data) = @_;

  #writeDebug("called isGroup($wikiName)");
  $data ||= $this->{data};

use Encode;
$wikiName = encode("iso-8859-1", $wikiName);

  return undef if $this->{excludeMap}{$wikiName};
  return 1 if defined($data->{"GROUPS::$wikiName"});

I highly doubt that this is a proper fix, but at least the wiki works for now.

-- AndreLichtsteiner - 24 Aug 2015

Could you please be a bit more specific about where it crashes? Why is it related to isGroup ?

-- MichaelDaum - 24 Aug 2015

In the browser I get:

Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.

Wide character in subroutine entry

And Foswikis error.log stats:

| 2015-08-24T11:11:06+02:00 warning | Wide character in subroutine entry at / <...> /lib/Foswiki/Contrib/LdapContrib.pm line 1898.

-- Main.AndreLichtsteiner - 24 Aug 2015 - 12:20

Okay, problem reproduced. It stems from the fact that underscores are used as an escape character deriving a cUID from logins. This cUID is stored in the topic's change history.

Here is a patch that disables the cUID <-> login mapping. Note that this might break backwards compatibility of revision history. Please check.

-- MichaelDaum - 24 Aug 2015

Applied the patch testing. I don't get above error, but the usernames in topic histories get wrongly mapped.

I stay for the time being with my ugly hack.

-- Main.AndreLichtsteiner - 24 Aug 2015 - 14:07

Reworked the title to reflect current findings.

-- MichaelDaum - 24 Aug 2015

Yes, loggins with underscore are now possible - with a clearly indicated code hack.

The question remains about the cUID in RCS: In the past, underscores were escaped, so our RCS files are full of entries like mueller_5fn. Now, the same cUID is mueller_n.

What shall we do? Will underscores be officially supported, and we alter all out RCS Files, or will the escaped underscores remain?

-- Main.AndreLichtsteiner - 30 Jan 2016 - 10:57

While this Problem is solved for existing Ldap-Users, it is still there for "non-existing" or "Ex-Users" with "Underscore" in the Name:

Foswiki detected an internal error - please check your Foswiki logs and webserver logs for more information.

Malformed UTF-8 character (fatal)

We had User "schneider_c2" who left us by the end of Februray. Now, since he is not in our AD anymore, every Topic with "schneider_c2" in the "author" Meta-Field crashes with this UTF-8 Error. An existing user, mueller_c, works fine. A Fantasy-User, gaga_c2, fails with the same UTF-8 Error.

-- OliverSchaub - 20 Mar 2017

Latest releases of LdapContrib have a switch $Foswiki::cfg{Ldap}{UseCanonicalUserIDs} that allows to disable misinterpretation of underscores in user names.

-- MichaelDaum - 18 Sep 2017

I have been bitten also by this bug, and I think I have found a satisfying workaround for us who have lots of existing pages. make the CUID->email conversion only process underscores for the non-alphanumeric characters that can actually be in the logins, and ignore all the others. This way we avoid _xx be interpreted as a non-ascii byte that will crash the UTF-8 perl functions.

So, for logins that are emails with only the characters -_.@' respectively encoded as _2d _5f _2e _40 _27 Change the line 140 in lib/Foswiki/Users/LdapUserMapping.pm (in function mapcUID2Login) from:

$cUID =~ s/_([0-9a-f][0-9a-f])/chr(hex($1))/gei;

to:

$cUID =~ s/_(2d|5f|2e|40|27)/chr(hex($1))/gei;

Note: I suspect allowing any UTF-8 "safe" char (any ascii 7-bit char?) could work too, e.g: $cUID =~ s/_([0-9a-e][0-9a-f])/chr(hex($1))/gei;

-- ColasNahaboo - 22 Mar 2019

Commenting is disabled while not logged in