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:
- You have
$TWiki::cfg{PasswordManager} = 'none';
- You do not authenticate
view
, and
- 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?
--
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
- login name mapping fails when the login name filter is changed (Micha's login manager will help, but the TWikiUserMapper should really work)
- 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?)
- 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.
- the removal of the
TWikiUserMapping_
prefix makes it impossible to directly identify a cUID
- 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:
- 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
- Regardless of this settings, RCS is being called with the
cUID
and no longer with the Wikiname.
- 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:
- escaping login names - its a little too scary to do now
- 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.
- If I view a TWiki page as an unregistered, but authenticated user
haj@MY.DOMAIN
, TWiki greets me with "Hello DOMAIN".
- According to my TWiki.TWikiVariables,
%USERINFO%
expands to =haj@MY.DOMAIN, DOMAIN, =
- I can register (but read on), with my login ID correctly being displayed in the registration form.
- Mail to Admin and user are sent, the user topic is created. However, the section "My Personal Data" has no e-mail in it.
- An extra topic
Main.DOMAIN
is created, containing just a bullet with my e-mail address.
- After a browser restart I can log in and work as expected, but
%USERINFO%
does not display my mail address.
- 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.
- And here you are: If I want to register
pos@MY.DOMAIN
, then I get the ominous "Can not register twice".
- Guessing from the strange observation regarding the mail address, I manually deleted
DOMAIN.txt
and DOMAIN.txt,v
, and hooray:
- 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