Item4771: TWikiUserMapping fails with Corporate SSO

Trying to adapt 4.2 to our corporate intranet:

• All users are authenticated before they enter TWiki by Apache (i.e. $ENV{REMOTE_USER} is set)
• We use TWikiUserMapping because we want (and can) create "ad-hoc" groups, whereas our corporate LDAP has fixed rules for group creation
• We have PasswordManager = none because the web server is not allow to change users' passwords, and I don't need them (we have SSO based on mod_auth_kerb)
• We have AllowLoginName = 1 because we use "normal" wiki names in favour of our cryptic login IDs

First observation: Nobody can register because TWiki says "you are already registered" and quotes my login name. As I wrote: I am authenticated, but not registered. From a first glance at the code it seems that, because my login id is present in $this->{session}->{user}, userExists will always return true.

Second observation: After having manually adjusted TWikiUsers.txt I am recognized, but not with my wikiname from TWikiUsers: Left bar (and %WIKINAME%) still show my login ID.

From adding some print STDERR stuff it looks as if getWikiName and other routines are always called with my login ID (which contains a @ character) instead of a properly escaped cUID. The loaded user mapping hashes refer to the "escaped" cUID.

TWikiUserMapping.pm contains too many things for which I have not yet found a specification, e.g.:

    if (defined $cUID && !length($this->{mapping_id})) {
        # Normal behaviour; if there is no user mapping specified, it's ours
        return 1 if $cUID !~ /^[A-Za-z]+_/;
    } else {

What is that /^[A-Za-z]+_/ supposed to match? cUID escaping would create such things if there are "special" chars, but allow digits as well.

addUser checks for existing users by their password entry, which doesn't exist if I have no password management in TWiki.

I doubt I'll have much time to debug in the next days, I'm back to the old version for the moment.

-- TWiki:Main/HaraldJoerg - 04 Oct 2007

If this report is valid then it is a release blocker of the big ones.

So I installed right away the TWiki 4.2.0 beta 2 here at Motorola on a test server

I cannot see the same problem.

I can register with an ID of the format x12345 and it maps fine to KennethLavrsen.

To use a basic auth with Apache - like a corporate LDAP I need to

Authenticate just a few scripts - see below

 <FilesMatch "^(logon|viewauth|rename|rdiffauth|)$">
  require valid-user
 </FilesMatch>

Here are the essential setting I use in configure

$TWiki::cfg{UseClientSessions} = 1;
$TWiki::cfg{Sessions}{ExpireAfter} = 21600;
$TWiki::cfg{Sessions}{ExpireCookiesAfter} = 0;
$TWiki::cfg{Sessions}{IDsInURLs} = 0;
$TWiki::cfg{Sessions}{UseIPMatching} = 1;
$TWiki::cfg{Sessions}{MapIP2SID} = 0;
$TWiki::cfg{LoginManager} = 'TWiki::LoginManager::ApacheLogin';
$TWiki::cfg{LoginNameFilterIn} = '^[^\\s\\*?~^\\$@%`"\'&;|<>\\x00-\\x1f]+$';
$TWiki::cfg{DefaultUserLogin} = 'guest';
$TWiki::cfg{DefaultUserWikiName} = 'TWikiGuest';
$TWiki::cfg{AdminUserLogin} = 'admin';
$TWiki::cfg{AdminUserWikiName} = 'TWikiAdminUser';
$TWiki::cfg{SuperAdminGroup} = 'TWikiAdminGroup';
$TWiki::cfg{UsersTopicName} = 'TWikiUsers';
$TWiki::cfg{AuthScripts} = 'attach,edit,manage,rename,save,upload,viewauth,rdiffauth,rest';
$TWiki::cfg{AuthRealm} = 'Enter your TWiki.LoginName. (Typically First name and last name, no space, no dots, capitalized, e.g. !JohnSmith, unless you chose otherwise). Visit TWiki.TWikiRegistration if you do not have one.';
$TWiki::cfg{UserMappingManager} = 'TWiki::Users::TWikiUserMapping';
$TWiki::cfg{Register}{AllowLoginName} = 1;
$TWiki::cfg{Register}{EnableNewUserRegistration} = 1;
$TWiki::cfg{Register}{HidePasswd} = 1;
$TWiki::cfg{PasswordManager} = 'none';
$TWiki::cfg{AccessibleENV} = '^(HTTP_\\w+|REMOTE_\\w+|SERVER_\\w+|REQUEST_\\w+|MOD_PERL)$';

I hope you manage to give some feedback soon Harald. This one HAS TO WORK.

-- TWiki:Main.KennethLavrsen - 04 Oct 2007

Your setup works, but only because of three facts:

1. You have $TWiki::cfg{PasswordManager} = 'none';
2. You do not authenticate view, and
3. You do not have non-alphanumeric characters in your login.

I don't have an active directory at home, but managed to reproduce the situation with plain userids:

If I set $TWiki::cfg{PasswordManager} = 'TWiki::Users::HtPasswdUser'; and the user already has his entry in .htpasswd, registration fails because it tells me that the user is already registered.

If I authenticate view as well (so that the user has to log in before registering), the symptoms are the same, regardless (!) of the setting of PasswordManager.

If I have view unauthenticated, no password manager but external Apache authentication with non-alphanumeric userids (in my case I've used a Kerberos principal haj@MYNOSPAM.DOMAIN) then registration "sort of" works:

Thank you for registering

    * Your personal TWiki topic Main.haj@MYDOMAIN has been created
      (Suggestion: How about uploading your picture to your topic?)
    * You are also listed in the TWikiUsers topic

Note that it does create the correct topic Main.HaraldJoerg and not Main.haj@MYDOMAIN. Main.TWikiUsers looks fine as well.

Henceforth I can login as haj@MYNOSPAM.DOMAIN, however TWiki will not map that to HaraldJoerg, and, of course, saving any topic will fail because it tries with the unescaped '@':

 Error saving topic
During save of Sandbox.HajsTopic an error was found by the version control system. Please notify your TWiki administrator.

=/usr/bin/ci -m%COMMENT|U% -t-none -w%USERNAME|S% -u %FILENAME|F% of .../Sandbox/HajsTopic.txt failed: 1 =

Go back in your browser and save your changes locally. 

-- TWiki:Main.HaraldJoerg - 04 Oct 2007

The regex that prevents any login name needs to be fixed for sure.

But the problem with authenticating view I am not sure is a real problem.

You should NEVER authenticate view when you use sessions. It is not recommended in the installation doc and it gives a major performance hit because your SSO needs to be asked at each page view.

• In this case, I don't care for "recommended". I have no performance problem (the server doesn't have to consult the active directory for each hit), and it has benefits, like user preferences and personal left bars being correctly interpreted right from the start. Login is going on "behind the scenes", so nobody needs to type in a password. -- TWiki:Main.HaraldJoerg - 04 Oct 2007

If you need people to not have access to viewing anything - which is also the case in our setup at Motorola - simply add a DENYWEBVIEW = Main.TWikiGuest to all webs. That is what I have run with since Cairo and it works great.

When guest cannot see anything they need to authenticate to view any page including the registration page.

I do not think anything in this respect changed since Cairo and Dakar.

But we need that new TWikiUserMapping to accept any login ID including non English letters.

-- TWiki:Main.KennethLavrsen - 04 Oct 2007

When you try to emulate the authentication with external auth, then you need to set $TWiki::cfg{PasswordManager} = 'none'; Otherwise TWiki will prevent registration - as it should. That is one of the means we have to block spammers in some cases (hack password file and change password and email address to funny address).

• In previous discussions we always had the use case "existing user base in system-wide .htpasswd wants to use new TWiki", and it has been advertised that TWikizens can change their .htpasswd passwords using TWiki. The facts that the file name for .htpasswd is configurable and that the password manager is "pluggable" comes from this considerations. So, either that use case is declared no longer supported or the bugs are fixed.-- TWiki:Main.HaraldJoerg - 04 Oct 2007

The $TWiki::cfg{LoginNameFilterIn}, did you remove the @ from the regex?

• Yes, of course. I forgot to mention that. -- TWiki:Main.HaraldJoerg - 04 Oct 2007

-- TWiki:Main.KennethLavrsen - 04 Oct 2007

That said, I got registration sort of "working" with the help of your example and a bit of hacking:

• I do the login name canonicalisation myself (in bin/LocalLib.cfg so that it survives upgrades. That file is still a nice place for dirty tricks ),
• I have view unauthenticated,
• I have no password manager (I had that before).

-- TWiki:Main.HaraldJoerg - 04 Oct 2007

Well. It seems there is still a bug to fix. What kind of hack did you do in bin/LocalLib.cfg?

Sven Dowideit - are you following this bug item? Any comments so far?

-- TWiki:Main.KennethLavrsen - 05 Oct 2007

My change in LocalLib.cfg? As trivial as can be, just a WFM hack and clearly no solution:

# (haj) hack #1: get rid of the darned @ in our user ids.  
# Kill the realm for now.
if ($ENV{REMOTE_USER}) {
    $ENV{REMOTE_USER} =~ s/@.*$//;
    $ENV{REMOTE_USER} = lc $ENV{REMOTE_USER};
}

-- TWiki:Main.HaraldJoerg - 05 Oct 2007

Instead of hacking LocalSite.cfg I am using a Kerberos login manager that takes care of sanitizing the login name.

-- MichaelDaum - 05 Oct 2007

No, Michael, you don't use it, at least not in 4.2. Your base class has been renamed from TWiki::Client::ApacheLogin to TWiki::LoginManager::ApacheLogin recently.

Writing a pluggable module to work around a core bug and having to update the workaround for the next version doesn't seem to be much of a progress.

-- TWiki:Main.HaraldJoerg - 06 Oct 2007

Harald, could you do me a favour and attach your LocalSite settings? I'm not quite sure that I understand your configuration choices yet.

At the moment, I think there are a couple of bugs brought up by Harald's testing

1. login name mapping fails when the login name filter is changed (Micha's login manager will help, but the TWikiUserMapper should really work)
2. if you set up TWiki to use an externally managed pwd system, and allow adhoc registration just to add the user topic and the TWikiUsers mapping, registration fails (this is also the case in 4.1.2?)
3. setting PasswordManager to 'none' (but still using auth&mapping) is interesting, as TWiki thus has no way to confirm whats going on, but its obviously its an important case.

-- TWiki:Main.SvenDowideit - 06 Oct 2007

Unfortunately, the mapping failure is due to several factors playing badly.

1. the removal of the TWikiUserMapping_ prefix makes it impossible to directly identify a cUID
2. the setting of {PasswordManager} to none, makes it impossible to directly identify a loginname (this is used in TWikiUserMapping::getLoginName())

I have checked in a change that I think not only fixes the problem, but also does what Cdot and I intended when we started the cUID change - ensure that the cUID is a garuanteed valid string for rcs, and other restricted character set internals that TWiki might encounter.

Harald and Micha, could you please test this change - it should mean that you don't need to apply any hacks to correct the login name.

I would like to move the adhoc registration when there is an existing password entry, and PasswordManager is NOT set to none to a new bug Item, that can be addressed post 4.2.0, as this is not a new regression (?please confirm), but rather how 4.1 also works.

-- TWiki:Main.SvenDowideit - 06 Oct 2007

I'll attach the configuration as soon as I've managed to get aTWikiRelease04x02 branch up and running (until yesterday I had just MAIN and 4.2B2).

About setting PasswordManager to 'none' (but still using auth&mapping) is interesting: That is what describes our use case best: We delegate authentication to Apache (who in turn delegates it to Active Directory), but useTWikiUserMapping for authorization because the corporate-wide directory is too inflexible.

I just stumbled over Item4605 (actually, over the expert setting {RenderLoggedInButUnknownUsers} and then made my way back). That rings a bell: Back in 2005, I wrote TWiki:Codev.UnregisteredUsersShouldBeTWikiGuests and I have a local patch in our corporate 4.0 which implements this (unconditionally). But this setting is unchecked per default, so things "should work".

Our corporate TWiki is 4.0 before user mapping entered the game, but with a bunch of patches regarding user management which never made it into core because I've been to late and was hit by 4.0 feature freeze.

Before I forget: Another one of my very stable patches in LocalLib.cfg makes the login id lowercase. Windows authentication is case-preserving, but case-insensitive. I didn't find a config setting for that.

I agree that the bug item should be split if the different issues I've collected from the symptoms turn out to be of different priorities. I simply hoped there would be a one-liner which would magically turn things right.

-- TWiki:Main.HaraldJoerg - 06 Oct 2007

Ah - getting better Revision 15175:

• ApacheLogin, no password manager, view unauthenticated, non-alphanumeric userid:
  • Registration works.
  • Editing topics works, my Wikiname is displayed in the signature (and elswhere where I'd expect it).
  • Re-visiting the site works, I am unauthenticated on view, and after login or editing I can authenticate and get my Wikiname.
  • Minor issue: TWiki insists on converting kerberos principals to mail addresses. Since both allow the same syntax, TWiki can not discern. So, in TWikiUsers, login names should be escaped properly (which they should anyway, just in case your login name is <script> )
• ApacheLogin, no password manager, view authenticated, non-alphanumeric userid:
  • On view I log in, but TWiki still calls me guest and TWikiGuest in %USERNAME% and %WIKINAME%, respectively. I don't mind TWikiGuest (to be precise, this is what I want), and I can live with guest.
  • Another minor issue of being called guest is that there's no way to correlate Apache's log (which has my "true" login id) to TWiki's log200710.txt file. If you're concerned about audit, don't allow editing by TWikiGuest.
  • Editing a topic which is forbidden for TWikiGuest yields oopsaccessdenied. I'd prefer if it would point me to registration instead, but that's a minor issue.
  • Registration works, my login id is provided as a default.
  • Editing, Re-visiting, and converting login name to mail addresses on Rendering work as above.

That's it for today

-- TWiki:Main.HaraldJoerg - 06 Oct 2007

Setting PasswordManager to 'none' but still using auth&mapping is as I already listed above how we run too. I do not see this as a special usecase. On the contrary. I think this is how most corporate/large installations are setup. Authentication taken care of by Apache via LDAP or active directory or some other SSO. But still using the TWiki registration to get nice WikiNames and to create groups, because in most corporations usernames are random characters and you have no influence on a corporate LDAP server for groups etc.

In our TWiki installation however I do not wish unregistered - but authenticated users - to be guests. I do not want to force registration on occasional users and I need to know the difference between an unauthenticated guest (who can see nothing) and an authenticated user.

-- TWiki:Main.KennethLavrsen - 06 Oct 2007

Kenneth: From a conceptual point of view, "unauthenticated guest (who can see nothing)" is the same thing as my practice of authenticating view access. So I guess it is simply for performance reasons that you use the 1) login, 2) session cookie for view approach?

I do not want to force registration of occasional users, too. Nice to see that our use cases regarding authorization are more or less identical

I hope this doesn't lead to other use cases being less thoroughly tested

-- TWiki:Main.HaraldJoerg - 06 Oct 2007

After applying the patches 15169/15170 to my corporate beta 2, things work as expected: The only patch I still need to apply is to convert the userid to lowercase (which I had in place since 4.0).

So this is, to my current knowledge, the summary of differences between 4.1 and 4.2:

1. For the default value of {RenderLoggedInButUnknownUsers}, unregistered, but authenticated users are treated as:
   • Wikiname TWikiGuest (resp. {DefaultUserWikiName})
   • loginname guest (resp. {DefaultUserLogin}): needs to be discussed with regard to urgency
2. Regardless of this settings, RCS is being called with the cUID and no longer with the Wikiname.
3. The history view for "old" topics sort of "accidentally works" because, if the name in ,v can not be mapped as a login name, will be displayed "as is" - and previous versions had the Wikiname in RCS.

As a consequence of the first two points, this item must go through "Waiting for Release" because the change needs to go into the release notes.

-- TWiki:Main.HaraldJoerg - 08 Oct 2007

Harald, I'm thinking of commiting the case insensitive login names in 4.2.0 too, as its pretty much the normal expectation everywhere - and to add a cfg to revert to the old way in the rare case that it might actually be desired.

The issue you have with guest - if you want the login name of TWikiGuest to be TWikiGuest you can set that in configure (you can control both the login and wikinames of the guest and internal admin user.

ok, things i propose to have as bugs to be looked into in furture releases:

1. escaping login names - its a little too scary to do now
2. What Kenneth asks - user is un-registered in twiki, but authenticated, thus login & cUID are known, and TWiki uses them (without breaking Haralds use case). - sounds like yet another setting

-- TWiki:Main.SvenDowideit - 08 Oct 2007

Sorry, I've bee too optimistic (probably mixing up changes in Apache and TWiki configuration) - there's still something missing.

• Apache config:
  • view is authenticated
  • User has been added to data/.htpasswd using the htpasswd command
• TWiki configuration:
  • {LoginManager} = TWiki::LoginManager::ApacheLogin
  • {PasswordManager} = none
  • {Register}{AllowLoginName} = 1
  • {RenderLoggedInButUnknownUsers} = 0

I do not recall how I managed to be authenticated but still identified as guest/TWikiGuest if not registered, and whether I managed at all or simply forgot to restart the server at some point. If I try today:

• TWikiRegistration will show me the form with the correct default for login id
• On "Submit", TWiki complains: You cannot register twice, the name 'loginname' is already registered.

The same thing happened when a colleague tried to register in our corporate installation where I had Sven's patches applied to 4.2B2.

I am pretty sure that it has to do with the current $ENV{REMOTE_USER} being implicitly applied to the user list regardless of whether he is registered or not: Under my own user ID, I could fill the form for the colleague, enter his login name, and complete registration. Mails are sent out correctly.

-- TWiki:Main.HaraldJoerg - 09 Oct 2007

yes, it does have to do with the $ENV{REMOTE_USER} , but I also suspect you of being in the TWikiAdminGroup, which means alot of other restrictions are lifted.

I'm going to attempt to change the registraiton code such that:

• TWikiGuest can register as any user not already in the system
• an Authenticated user can register with that login only, assuming there is no real existing usermapping
  • Please don't implement this. See below where both Harald and I agree that it is OK to register others --KJL
• an Admin user can register as any user that has no real existing usermapping

-- TWiki:Main.SvenDowideit - 13 Oct 2007

Watch out. I find it a very good feature to be able to register other people for them. Bulk registration also has to work.

The reason this is a good thing is

• It is not really a security issue that you register someone else.
• When we put access rights on a topic to a user who is not yet registered we often simply register the guy. This way the WikiName and therefore the access to the topic cannot be stolen by anyone else. And the "not so keen on learning TWiki" guy gets an email that he is registered. Helps getting those slow guys started on TWiki.

It is not only admins that does this.

It is important that you cannot register with a WikiName or login that already exists in TWikiUsers but that we have already. That works.

Actually the biggest problem I have had with registration is when someone writes a non-existing username and someone else clicks the ?-mark and creates a Main topic. Then later this person cannot register. I have had to remove such bogus topics quite often. One more reason why we register the users that have not registered yet.

I think this is a typical "Watch out what you ask for - you might get it" example. I actually think the registration and access features work quite well now. The only missing feature I miss is ONE place to put a global DENYTOPICACCESS to TWikiGuest. Today I have to add it to all webs in WebPreferences. And I still think this is what Harald should do instead of authenticating view.

-- TWiki:Main.KennethLavrsen - 13 Oct 2007

Sven assumes: but I also suspect you of being in theTWikiAdminGroup, which means alot of other restrictions are lifted. No, I'm not. I'm just starting up a fresh browser and trying to register as someone else who is authenticated using corporate SSO.

Kenneth: I agree that the possibility to register other people is a must-have. But not authenticating view is not an option for me. If a whole server is authenticated and TWiki is just a part of it, it is a really annoying exercise in Apache configuration to have some parts not authenticated. There is no DontRequire in Apache!

Now on the bug itself: I've been yet unable to fit the scenario into the unit tests, which have their own problems (Item4800). I have managed to reproduce the bug from the command line, but only by explicitly not using TWiki's "command_line" environment, which always defines a user to create the TWiki object. Fortunately CGI.pm is quite capable to be run from the command line.

The first bug which needs to be fixed is in the two lines of TWikiUserMapping::userExists:

    # Do this to avoid a password manager lookup
    return 1 if $cUID eq $this->{session}->{user};

If the request is authenticated, $this->{session}->{user} is initialized to $cUID in any case, regardless of whether the user is registered.

Simply removing that line doesn't cut it either, because now the user can register multiple times, each time having his login name appended to his Wikiname in TWikiUsers.

The statement return 1 if $cUID !~ /^[A-Za-z]+_/; is a boolean random number generator because its outcome depends on whether there were special characters, but no numbers in the original login.

Need to continue with RL now...

-- TWiki:Main.HaraldJoerg - 13 Oct 2007

I can confirm that you cannot register if you are authenticated and view is authenticated by TWiki.

The registration should only be blocked if one of the following conditions are met.

• The login name is already in TWikiUsers
• The Wikiname is already in TWikiUsers
• The Wikiname exists as a topic in Main
• The registration is disabled in configure
• the user exists in the htpasswd file, and allowLoginName == false (in this case the TWikiUsers topic is ignored)
• there are other cases that are in use

Who will fix this? It is a release blocker.

I only see two outstanding issues on this bug item.

• Fix the problem with registration when view is authenticated
• Fix the problem with the user ID containing numbers and other non-english characters. IF there is a problem.
  And Sven. Can you please comment on the return 1 if $cUID !~ /^[A-Za-z]+_/;?

  -- TWiki:Main.KennethLavrsen - 14 Oct 2007

  I'm still trying to work up a way to solve this, while retaining the other use cases.

  wrt to the 'boolean random number generator' - that code is a left over from the removeabl of the mapper prefix. I'm not quite sure when it becomes useful, so I'm treating it with caution, while cleaning up for an initial release of OpenIDUsersContrib to test the concepts, now that those changes have happened.

  I'm afraid that its not going to be a rush job this late in the piece.

  -- TWiki:Main.SvenDowideit - 17 Oct 2007

  so far, each change I've made has resulted in test failures, and the new tests I'm adding aren't exactly consitently fine - Its happening, just not quickly.

  -- TWiki:Main.SvenDowideit - 10 Nov 2007

  after many repeats ofthe same tests with different settings, I think I've solved it. Harald & Kenneth - time for you guys to test.

  -- SvenDowideit - 15 Nov 2007

Will test at Motorola. Harald though is the most important tester.

-- TWiki:Main.KennethLavrsen - 19 Nov 2007

Still fails in my real world scenario. There is a major issue, and a minor one. The major one is to a piece of code which I've criticised before:

Index: twikiplugins/TWikiUserMappingContrib/lib/TWiki/Users/TWikiUserMapping.pm
===================================================================
sub handlesUser {
       my ($this, $cUID, $login, $wikiname) = @_;

    if (defined $cUID && !length($this->{mapping_id})) {
        # Normal behaviour; if there is no user mapping specified, it's ours
        return 1 if $cUID !~ /^[A-Za-z]+_/;
    } else {

With mod_auth_kerb, login ids have the syntax haj@MY.REALM, converted to haj_64MY_46DOMAIN by the canonicalizer. This happens to have exactly the syntax which handlesUser will now reject. So, TWikiUserMapping calls itself not responsible, it falls back to base, and base passes the canonical user id if it isn't one of the predefined ones.

After logging in, it greets me with

  Hello haj_64 MY_46 DOMAIN

That's not what I want to add to TWikiAdminGroup nor use in access control.

The minor issue is that after registering someone else I am sort of "logged in" as this someone else, at least in the left bar. Probably this happens because the cookie "login state" is changed after registration to whoever has registered. It is straightened out as soon as I edit something, because edit wants genuine authentication and starts with $ENV{REMOTE_USER}. Maybe this should go to an extra bug item.

Don't spend too much time on fixing this just for me, though. I needed to get a running version before these recent patches were available. I've changed quite a bit in user management in my installation (basically by removing lots of stuff I don't need) because I had to prepare for automatic LDAP-based registering (again). The current svn diff has some 700 lines, not only in user mapping, but also in TWiki.pm and TWiki/Users.pm (most of them cosmetic). Our corporate intranet went SharePoint on 1st of November. I am currently struggling to integrate my TWiki installation as smooth as possible, which means I'll have very little time to test SVN based TWikis.

-- TWiki:Main.HaraldJoerg - 20 Nov 2007

Harald! thankyou for the detail - I couldn't quite see how the line of code was causing your problem, so i fixed the 'real' reason - there was code in register specifically dissallowing registering as the user that was logged in.

I suspect just removing it is fine, I'm just not positive - which was one of the reasons i was taking so long to remove the mapping_ prefix from the cuid's.

as to the 'minor' issue, y, thats been bugging me (conceptually) for a few weeks, and I'm trying to figure out why we can't remove that, forcing users to actually log in after they have completed registration (or in your senario, they have already logged in)

can you tell me how it works if you just remove the return 1; line ? I'm reasonably sure it will work fine, its just a legacy of the way Crawford did the change when he removed the TWikiUserMappin_ prefix, and I also can't see a functional use for it (since some of the other refactorings I did afterward)

-- TWiki:Main.SvenDowideit - 21 Nov 2007

I've moved the 'minor' registration issue to Item5008

-- TWiki:Main.SvenDowideit - 23 Nov 2007

removed the magic number creator, and fixed the 'thanks' oops message to show actual user topic created. I think we're all good - Kenneth - what does your TWiki show?

-- TWiki:Main.SvenDowideit - 23 Nov 2007

Normal editing and save works. And setting Deny to TWikiGuest also works.

However I see a glitch that could be a mapping issue with EditTablePlugin. I have opened Item5014

-- TWiki:Main.KennethLavrsen - 23 Nov 2007

I have nothing in this bug report to be dis-pleased about. So it is Harald's call to say if he is happy.

-- TWiki:Main.KennethLavrsen - 24 Nov 2007

Unfortunately at the office I'm now having conflicts with SVN in Users.pm and TWikiUserMapping.pm, and I won't be able to investigate since I am out of office next week. From inspecting the SVN code, it looks fine (read: sufficiently similar to my own), though I still don't understand most of the user id conversions.

I've done some tests in my mockup at home with a pure SVN HEAD, and the following config settings:

$TWiki::cfg{LoginManager} = 'TWiki::LoginManager::ApacheLogin';
$TWiki::cfg{LoginNameFilterIn} = '^[^\\s\\*?~^\\$%`"\'&;|<>\\x00-\\x1f]+$';
$TWiki::cfg{PasswordManager} = 'none';
$TWiki::cfg{Htpasswd}{FileName} = '/not/for/twiki';

• I can, while logged in as haj@MYNOSPAM.DOMAIN, register sav@MYNOSPAM.DOMAIN, and then login as this user. Works as expected.
• I can log in as an unregistered user frc@MYNOSPAM.DOMAIN (which I consider somewhat similar to my office use case in the case of "guests"):
  • %WIKIUSERNAME% expands to Main.DOMAIN,
  • %USERINFO% expands to =frc@MY.DOMAIN, DOMAIN, =
  • I can still not (or again not?) register because of "You cannot register twice, the name 'frc@MY.DOMAIN' is already registered."
  • I don't know how, but I am having a topic Main.DOMAIN consisting of a plain mail address (which was of no help since I always use the same address for testing)-

This is just a simulation, so I don't know whether this is really relevant to the cause.

-- TWiki:Main.HaraldJoerg - 25 Nov 2007

ok, though this is pretty much what I tested too, your results are different to mine. We'll have to continue looking until we can be sure it works. Hope to hear more from you after next week.

The rendering of WIKIUSERNAME and USERINFO i've not looked into at all - its somewhat related to the existing bugs in about the problems with nests (or non-nested) webs and the use of the dot. These should be moved into another bug, for future consideration

The cannot register twice worked in my testing - so more testing is obviously needed - I still havn't figured out a set of unit tests to represent this case.

Main.DOMAIN, mmm, I wonder what happened, I made changes to that code.

wrt the user id conversions, yeah, nor do I atm, the confusion is due to the removeal of the TWikiUserMapping _ prefix, and all the backward compatible code, necessitating lots of extra fuzz. The rather cool bug kenneth found in Item5014 is probably going to make me revisit each of them in the debugger because the password = none case really is painfully different.

-- TWiki:Main.SvenDowideit - 25 Nov 2007

The fog is clearing. Or maybe thickening. I have no idea.

My observations from the mockup were basically correct, at least I could reproduce them with RC1. I did a clean installation to a new directory.

1. If I view a TWiki page as an unregistered, but authenticated user haj@MY.DOMAIN, TWiki greets me with "Hello DOMAIN".
2. According to my TWiki.TWikiVariables, %USERINFO% expands to =haj@MY.DOMAIN, DOMAIN, =
3. I can register (but read on), with my login ID correctly being displayed in the registration form.
4. Mail to Admin and user are sent, the user topic is created. However, the section "My Personal Data" has no e-mail in it.
5. An extra topic Main.DOMAIN is created, containing just a bullet with my e-mail address.
6. After a browser restart I can log in and work as expected, but %USERINFO% does not display my mail address.
7. Now it gets interesting: With another browser I start a new session with another authenticated, but unregistered user pos@MY.DOMAIN. This user is, as before, greeted with "Hello DOMAIN". The real surprise is his display for %USERINFO%: It shows the email address of the user I've registered before. It pulls the mail address from the mysterious DOMAIN.txt! I could easily prove it by changing the contents of DOMAIN.txt with vi and reloading the page.
8. And here you are: If I want to register pos@MY.DOMAIN, then I get the ominous "Can not register twice".
9. Guessing from the strange observation regarding the mail address, I manually deleted DOMAIN.txt and DOMAIN.txt,v, and hooray:
10. I can successfully register pos@MY.DOMAIN. But again, DOMAIN.txt is back, with the intentionally bogus mail address I entered when registering pos@MY.DOMAIN.

Bottom line: With RC1, one user is able to register, no notification or other services requiring a mail address work.

-- TWiki:Main.HaraldJoerg - 01 Dec 2007

Harald. That tells me pretty much everything. And it does, as you say , boil down to the email address problem, which I should be able to tidy away easily.

I'll poke the 'Hello DOMAIN" problem, just in case I can make that 'simply' work, heck, maybe we're lucky, and it leads me to the root cause of Item5014

-- TWiki:Main.SvenDowideit - 03 Dec 2007

well. This and the results of Item5014 have required some re-writing of host we identify user info, though I'm much happier with the code, as it now refuses to deal with things it does not understand.

Harald and Kenneth, can you bash on it a little? I know of one issue atm - related to 5014 - if the authenticated, but non-registered user uses EditTablePlugin, it doesn't like it.

If I apachelogin as TestEmail@home.org.au, it now calls me TestEmailhomeorgau (I've removed the dot's and other NameFilter characters), then, when I register as that user, the email works, and I am displayed as TestEmailPerson, or whatever I choose as wikiname.

-- SvenDowideit - 06 Dec 2007

Weeell... It seems to work, with minor quirks (the login name of the authenticated user is no longer displayed in the registration form). But I am not happier with the code, which gets more and more bloated - and the bloat is in Users.pm and not in any of the sophisticated mappings.

-- TWiki:Main.HaraldJoerg - 06 Dec 2007

I found Item5091 while testing this but the original symptom of this bug item seemed fixed.

I can register with PasswordManager none even when I am authenticated.

-- TWiki:Main.KennethLavrsen - 06 Dec 2007

Harald - I'm not sure I see what you mean about bloat. The Mappings are not supposed to be sophisticated. They are like the DBD drivers, a way for TWiki to get the info it needs.

On the other hand, there is alot of bloat due to the need to support all sorts of compatibility with previous releases, and that needs to be hidden in TWiki, so that it works the same way when new usermappings are written. otherwise, plugins will break much more.

I guess I'll have to do a quick function point & complexity analysis to see if what you say is justified - but really, I am trying to reduce the cimplexity and TWiki specificness of the plugable components, to make it simpler to write new ones.

Lets call this bug sorted, and tract any new issues in new bugs.

-- TWiki:Main.SvenDowideit - 07 Dec 2007

About bloat: I'm referring to lines like

$this->{getCanonicalUserID}->{$this->{getWikiName}->{$cUID}} = $cUID;

The current TWiki::Users object is a hash containing three hashes for {getLoginName}, {getWikiName} and {getCanonicalUserID}. Where would these all be used in TWiki requests? And in which cases would they be used often enough to justify a comprehensive caching in the Users object, for one single request?

The most complicated thing, according to the code in Users.pm, is apparently to find out which user mapper handles a given user. All that for just five hardwired users, of which most have no mail address, nor a login.

-- TWiki:Main.HaraldJoerg - 07 Dec 2007

the cacheing in Users is almost un-necessary.... except for those of you that want to log in and use an unregistered user. Though tbh, I'm working towards those being memcacheable, so we can speed up all requests.

You are right, the code that works out which mapper to use is the biggest complexity. It made the current code refactor possible, and enabled me to work out howto get the speedup we (should / did have before (still need to profile it) ) had - the usual thing, seperate the concerns, and the parts become simpler. Time will tell.

-- TWiki:Main.SvenDowideit - 07 Dec 2007

_the cacheing in Users is almost un-necessary.... except for those of you that want to log in and use an unregistered user. _ Sorry, that's plain wrong. Those of us don't need caching. For every request, we have at most one unregistered user who, at some stage in the process, should be assigned his cUID and mock-up wikiname. There is no need for a hash of login names (there is only one), and probably not even a performance benefit from hashing cUIDs.

-- TWiki:Main.HaraldJoerg - 08 Dec 2007

go debug the code. Seriously. "assigned his cUID and mock-up wikiname" is a cache. Shrug.

-- TWiki:Main.SvenDowideit - 08 Dec 2007