Item11263: Manipulation of REMOTE_USER for Apache Login

Hi,

I'm running foswiki 1.0.9 and use a customised version of ApacheLogin.pm to convert spaces in user login names to underscores ( '_' ). I was hoping that the same strategy of manipulating $authUser would work with Foswiki 1.1.3 but it runs into problems when I do things like

$authUser = lc $authUser;

Later when I try and edit a file and am logged in I get a '403' error from the Wysiwyg editor.

Could someone recommend a way in which REMOTE_USER can be manipulated so that extraneous white space is removed, the remaining space between elements of the user name is replaced by and underscore, and the whole thing is converted to lowercase?

eg

' nEIl McKETT ' -> 'neil_mckett'

Thanks.

Neil

-- NeilMcKett - 18 Nov 20

The underscore is an escape character internal to foswiki. Login Names are converted to a "cUID" (cannonical User ID) in Foswiki::Users in sub mapLogin2cUID. Case is preserved, so using your example the cUID would be nEIl_20McKETT

I don't believe that it was intended for this to be overridden - you could modify the regex on the left side of the statement to accept _ as a valid character. It is extremely important that the results only contain characters that are a legal user for the rcs system.

    $cUID =~ s/([^a-zA-Z0-9])/'_'.sprintf('%02x', ord($1))/ge;

I don't believe that we ever try to "convert back" from cUID back to login, so it is safe to have extra underscores in the cUID.

If you force the cUID to be lower case, you have to make sure that you don't get duplicates due to case differences in user names.

The cUID is documented in http://foswiki.org/System/PerlDoc?module=Foswiki::Users

-- GeorgeClark - 18 Nov 2011

---

Neil,

I've been bitten by this as well. At my University, all students have underscores in their LDAP usernames, which are rcs-escap-ified at storage time. What's really annoying, though, is that the escaped version isn't converted back when the values are queried or parsed. Therefore, we've had to fill our wiki-apps with ghettorific regex anytime we query or compare agains user id's. That is super-annoying, as that ties not just the query API, but the macros themselves to a very specific aspect of the storage engine, which may not always be the case.

On an unrelated note, why does this show up as a release blocker for 1.1.4? It's not tagged as next point release...

-- AaronFuleki - 20 Nov 2011

Aaron, Any "urgent" with a target of n/a will also show up as a release blocker. Probably so they don't get overlooked.

As far as query/parse of cUID - I thought they were purely internal to the rcs files and should be displayed and queried as the WikiName.

I'd be tempted to add underscore as a valid character by default, but I'm concerned about the impact this would have on existing mappings.

-- GeorgeClark - 20 Nov 2011

At the moment ApacheLogin.pm removes all spaces from login names. I can see the sense in this but I am concerned about collisions. It is quite possible that login names like 's anderson' and 'sanderson' could be confused hence my preference for replacing spaces with "_"'s

-- NeilMcKett - 24 Nov 2011

This probably rises to the level of needing a Development/FeatureProposal. Changing the transform for building the cUID from the LoginName or WikiName is potentially a dangerous change. My suggestion is:

• Don't change the default behavior
• Move the Regex from Foswiki::Users::mapLogin2cUID() into an expert parameter in the configuration

    $cUID =~ s/([^a-zA-Z0-9])/'_'.sprintf('%02x', ord($1))/ge;

• Add instructions that characters may be added to the regex with following cautions
  • Change to the regex for existing sites may break topic history by changing the cUIDs already in use in topics.
  • RCS has very restricted support for characters other than a-z and 0-9. Any changes to this regex could break the topic revision history

...

And the more I read into this, now I'm not sure. RCS defines the "id" parameter as follows

       delta     ::=  num
                      date       num;
                      author     id;
                       ...
       id        ::=  {idchar | .}+

       idchar    ::=  any visible graphic character except special

       special   ::=  $ | , | . | : | ; | @

       Identifiers are case sensitive.  Keywords are in lower case only.  The sets of keywords and identifiers can overlap.  
       In most environments RCS uses the ISO 8859/1 encoding: visible graphic charac-
       ters are codes 041-176 and 240-377, and white space characters are codes 010-015 and 040.

This seems to define a much broader range than a-zA-Z0-9

However a bigger issue - I didn't look far enough into the mappings. The mapping is indeed reversed in the TopicUserMapping. So user smith aaron would to smith_aaron, but would reverse to smith(0xaa)ron - converting spaces to underscore is not safe.

-- GeorgeClark - 26 Nov 2011

I've done some further digging and testing. Per man rcsfile and verified with tests, the period (.) is valid in a login id. If we allowed the period to pass through the login2cUID transform un-modified, the custom ApacheLogin could transform the spaces to periods.

Would this work for you? It's still a dangerous change to core, and would have to be optional. Changing login2cUID will break history.

-- GeorgeClark - 26 Nov 2011

Removing the Urgent - this really shouldn't block release of 1.1.4. This probably needs a proposal to fix the design.

-- GeorgeClark - 30 Nov 2011

Yes, replacing a space (' ') with a dot ( '.' ) is fine. It would also be good to have a way of filtering the username so that extraneous white space can be removed if desired. ie 'neilmckett' should resolve to neil.mckett as should 'neilmckett'. This is required because the company wide LDAP server I use for authentication does all this and people are used to entering login names without worrying about the amount of white space or the case of characters used for the login name. It was quite easy to update ApacheLogin in Foswiki 1.0.9 but in 1.1.x the same modifications cause errors in the Wysiwyg editor ( 403 ) .

Thanks.

-- NeilMcKett - 30 Nov 2011

Changing this to Needs Proposal. As noted above, changes in this area are a bit risky and needs review by others.

-- GeorgeClark - 07 Mar 2012

Commenting is disabled while not logged in