Development discussion for LoginNameAliasesPlugin

-- ClaussStrauch - 23 Jul 2004

Thanks for contributing this Plugin. Just some preliminary feedback:

• Do not assume the TWiki web, some users might install the Plugin in another web. Point to %TWIKIWEB%/SomeOfficialTWkiDoc; in the Plugin use $installWeb
• I do not recommend to add variables to TWiki.cfg to avoid upgrade problems. Define a LOGGING = on Plugin variable (on/off for security, not path) and hardcode the logging dir to TWiki::Func::getPubDir() . "/$installWeb/$pluginName/_logfile.txt"
• The zip contains the default logfile. To avoid gotchas, possibly add note to make sure that this file is writable by the Apache user
• It would help to have the TWiki:Plugins/Benchmark
• Small detail, the official TWiki URL is http://twiki.org/ (without the www)

-- PeterThoeny - 23 Jul 2004

I've changed the plugin and documentation to address the last 4 of the above suggestions. The first one will be addressed later, when AddInstallWebToInitializeUserHandler is implemented and released. A warning has been put in the documentation that things won't work if the settings topic is not in the TWiki web.

-- ClaussStrauch - 26 Jul 2004

Clauss - this looks useful, thanks.

Questions:

1. can it be used to allow people to log in using their email address?
2. do you manually update that login aliases file?
3. does it work with htaccess?

Thanks, M.

-- MartinCleaver - 29 Sep 2004

Much belated response (sorry 'bout the delay):

1. Yes, but you may have to do a bit of hacking. Simple case: everyone has the same e-mail domain (i.e. everyone is foo@yahooPLEASENOSPAM.com, for example), and one just removes the suffix, and TWiki can map "foo" to a TWikiName like it would any username. More general case: you need to put in a separate alias for each person, mapping their e-mail address to something TWiki can handle. Hacking case: add a bit of perl to nuke the @email.address part.
2. Yes, I manually update it.
3. Yes. For example, in my current setup, people use WebISO & Kerberos to authenticate to the web server. REMOTE_USER gets set to username@domain. The plugin maps this to a particular TWiki user (which may not be the same name as the username set in REMOTE_USER).

-- ClaussStrauch - 19 Nov 2004

I made some changes to the Plugin topic text. Mainly added SHORTDESCRIPTION, which is needed for the PluginPackage report and to show the Plugin description in TextFormattingRules if installed. You can take this back into the next release.

Also, how about measuring and documenting the PluginBenchmarks?

-- PeterThoeny - 30 Mar 2005

zip checked into CVS

-- WillNorris - 27 Jun 2005

Did rewrite prefs fetching and made some more modifications to get it working under dakar. It seems to be working alright with TWiki::Client::ApacheLogin . Tried dakar beta3, 7085 and 7162. Apache mod_auth_kerb and basic. Also case insensitivity may be needed for Aliases (perhaps when authenting *nix TWiki against windows domain). This patch should fix it:

--- LoginNameAliasesPlugin.pm.orig   2005-10-25 15:29:44.000000000 +0300
+++ LoginNameAliasesPlugin.pm  2005-10-25 15:47:33.000000000 +0300
@@ -191,7 +191,7 @@
 
         foreach my $l (split(/\n/,$text)) {
             my ($a,$u) = ($l =~ m/^\t+\*\sALIAS:\s(\S+)\s(\S+)\s*$/);
-            if (($a && $u) && ($a eq $loginName)) {
+            if (($a && $u) && (lc($a) eq lc($loginName))) {
               TWiki::Func::writeDebug( "ALIAS found:  $a -->  $u" ) 
                              if ($prefs{'DEBUG'});
                 $u =~ s/$sec_filter//go;

Hello

Can you explain the use of MAP_UNREGISTERED. I want to check that the user that is authenticating is registered in TWikiUsers. If I set this variable to something (like username guest) then guest is always returned. My problem is that people are accessing the TWiki without registering. They are authenticated by apache and the kerberos module but they bypass TWiki registration.

-- PeterJones - 01 Nov 2005

MAP_UNREGISTERED is for mapping unregistered users to a particular identity. It doesn't force people to register. There is a bit of discussion about this issue in TransparentAuthenticationRevisited.

-- ClaussStrauch - 01 Nov 2005

I tried the following:

• I set MAP_UNREGISTERED =
• I was able to edit LoginNameAliasesPlugin again (see below for problem)
• I tried to edit another page and was asked for a username. I gave a TWiki unregistered name but one that is real and authenticated by kerberos and this is accepted. This is what I want to avoid.
• I set MAP_UNREGISTERED = guest
• Now set I cannot edit the topic LoginNameAliasesPlugin (not authorised)
• I try to edit another topic and I am asked for a username. I give a known kerberos username and one not registered in Twiki. The logging shows the username returned to be guest. I then repeat the proocess but give a known kerberos username/password and one that is registered in TWiki and still the login returns the username guest.

So this means if I set the MAP_UNREGISTERED variable then I get wierd results. I would like to check what is happening elsewhere. Where does the debug info go.

-- PeterJones - 02 Nov 2005

You seem to suffer from the same problem which made me invent RegistrationOnDemandHack: TWiki is seeing "authenticated" and erroneously implies "authenticated and registered". TWiki doesn't play very well if it finds authenticated users without having asked for authentication itself. I intend to merge the good parts of my hack as a contribution to DakarRelease but I admit that I'm still struggling to get a reasonable test and debug environment running, so don't hold your breath....

-- HaraldJoerg - 02 Nov 2005

We have disabled registration on our site. I've written a script that does following:

• Fetches domain users data from Active Directory over LDAP.
• Adds new users to TWikiUsers
• Generates Main.FirstnameLastname page for new users with default values and some user specific data (title, email, phone etc.)
• Adds aliases to %TWikiWeb.LoginNameAliasePlugin to map loginname to FirstnameLastname.

When user leaves the company, then his page will remain or has to be removed manually. When user data changes, he's responsible to edit it himself.

-- LauriVihman - 07 Nov 2005

I have used this plugin as we have spaces in out user names. They are in the form "DOMAIN\First [space] Last". So I also had to change the regex as it does not allow for spaces. For the general case maybe the delimiter should be a preference setting.

It doesn't fix my issue with rcs though RcsAndSpacesInUserNames

Thanks

my ($a,$u) = ($l =~ m/^\s+\*\sALIAS:\s([^=]+)=(\S+)$/);

-- AdamStraughan - 17 Nov 2005

LauriVihman: Can I see this script? I'm particularly trying to query AD information over LDAP. Thanks!

-- RyanWoerth - 30 Nov 2005

Has anyone gotten this plugin to work with TWiki Release 4.0.2?? I get 'TWiki::Plugins::LoginNameAliasesPlugin::earlyInitPlugin failed: 1 ' on my Plugin Diagnostics. Thanks

-- JayPHolland - 11 Apr 2006

Plugin version by LauriVihman (in attachment) works with 4.x.x, but code for handling MAP_UNREGISTERED works wrong; here is patch:

--- LoginNameAliasesPlugin.pm   2005-10-25 02:09:41.000000000 +0600
+++ ../LoginNameAliasesPlugin.pm        2006-04-12 20:42:42.000000000 +0600
@@ -243,8 +241,8 @@
 # Looks for key in %TWiki::userToWikiList
 
   if ($prefs{'MAP_UNREGISTERED'}) {
-     unless (TWiki::Func::userToWikiName($loginName,0) ne '') { # Back to safe TWiki::Func space again. L.V.
-       # unless (exists($TWiki::userToWikiList{$loginName})) {
+     my $wikiname = TWiki::Func::userToWikiName($loginName);
+     if( !( length($wikiname) && TWiki::Func::topicExists('',$wikiname) ) ) {
              $loginName = $prefs{'MAP_UNREGISTERED'};
              $loginName =~  s/$sec_filter//go;
              _dologging($logFile, $original_loginName, $loginName) if ($prefs{'LOGGING'});

-- NikitaSmirnov - 12 Apr 2006

I have problems getting this plugin to work on 4.1.1 I am using the Dakar plugin (24 Oct 2005 - 22:05).

LoginNameAliasesPlugin/_logfile.txt does not show anything for

the username that was passed to the plugin and the username that the plugin returned.

$ENV{'REMOTE_USER'} shows me as pete@CERN.CH

I have the same setting as for 4.0.5.

Has anyone tested this successfully on 4.1.1 ?

-- PeterJones - 13 Feb 2007

I have tested this on 4.1.2 and it works! (for removing the suffix. I have not tested the alias). See my question at LoginNameAndNTLMProblem. I'll upload the dakar version to the site LoginNameAliasesPlugin

-- ChengappaCB - 10 Jan 2008

Can anyone give a patch / solution to make the REMOVE_PREFIX case insensitive ? I have used this great plugin in my office to remove the prefix DOMAIN. But it does not remove it if a user logs in with domain (lowercase). I would like it to remove the suffix irrespective of the case

-- ChengappaCB - 19 Jun 2008

Hi, anyone knows how to use this in version 5? I enabled the plugin in configure, but it does not seem to work.

-- WangShida - 2011-12-26

Same here -- I think I have it installed correctly, but it doesn't appear to do anything at all.

-- MitchKutzko - 2012-05-15

This plugin needs some TLC, it is indicated that it is TestedOnTWiki only on TWiki-4.1.

TWiki is open source software. I invite you to get involved, fix/enhance part of TWiki, and contribute it back to the community. More at ReadmeFirst.

-- PeterThoeny - 2012-05-16

Has anyone been able to get this working with TWiki 6.0.0? I don't think there is a TWiki.cfg file in 6.0.0; it's now LocalSite.cfg. I installed the files and enabled the plugin via configure. Twiki shows the plugin as (disabled).

-- Jerry Yablonkai - 2014-08-27

This plugin is very old and has not been updated. It might break. In any case, define configure settings now in lib/LocalSite.cfg.

-- Peter Thoeny - 2014-08-27

Likely the $TWiki::useLoginNameAliasesPlugin test needs to be fixed or removed in the code.

-- Peter Thoeny - 2014-08-27

Getting further... TWiki::Plugins::LoginNameAliasesPlugin::earlyInitPlugin failed: 1 I looked at the code and it says to refer to SessionPlugin, which is no longer used.

-- Jerry Yablonkai - 2014-09-02

The reference to the SessionPlugin is just in a code comment. I invite you to fix and enhance the plugin and contribute this back to the TWiki community. Alternatively, you could hire a TWiki consultant to do that for you.

-- Peter Thoeny - 2014-09-02