AppliesTo: | Component: | Priority: | CurrentState: | WaitingFor: | TargetRelease | ReleasedIn |
---|---|---|---|---|---|---|
Engine | TWikiUserMapping | Urgent | Closed | minor | 4.2.0 |
$ENV{REMOTE_USER}
is set)
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)
AllowLoginName = 1
because we use "normal" wiki names in favour of our cryptic login IDs
$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:
$TWiki::cfg{PasswordManager} = 'none';
view
, and
$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 topicNote 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.
$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).
.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
bin/LocalLib.cfg
so that it survives upgrades. That file is still a nice place for dirty tricks ),
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
TWikiUserMapping_
prefix makes it impossible to directly identify a cUID
{PasswordManager}
to none, makes it impossible to directly identify a loginname (this is used in TWikiUserMapping::getLoginName())
{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:
view
unauthenticated, non-alphanumeric userid: <script>
)
view
authenticated, non-alphanumeric userid: 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
.
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.
oopsaccessdenied
. I'd prefer if it would point me to registration instead, but that's a minor issue.
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:
{RenderLoggedInButUnknownUsers}
, unregistered, but authenticated users are treated as: TWikiGuest
(resp. {DefaultUserWikiName}
)
guest
(resp. {DefaultUserLogin}
): needs to be discussed with regard to urgency
cUID
and no longer with the Wikiname.
,v
can not be mapped as a login name, will be displayed "as is" - and previous versions had the Wikiname in RCS.
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:
view
is authenticated
data/.htpasswd
using the htpasswd
command
{LoginManager} = TWiki::LoginManager::ApacheLogin
{PasswordManager} = none
{Register}{AllowLoginName} = 1
{RenderLoggedInButUnknownUsers} = 0
You cannot register twice, the name 'loginname' is already registered.
$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:
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.
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
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 DOMAINThat'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';
%WIKIUSERNAME%
expands to Main.DOMAIN,
%USERINFO%
expands to =frc@MY.DOMAIN, DOMAIN, =
Main.DOMAIN
consisting of a plain mail address (which was of no help since I always use the same address for testing)-
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. haj@MY.DOMAIN
, TWiki greets me with "Hello DOMAIN".
%USERINFO%
expands to =haj@MY.DOMAIN, DOMAIN, =
Main.DOMAIN
is created, containing just a bullet with my e-mail address.
%USERINFO%
does not display my mail address.
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.
pos@MY.DOMAIN
, then I get the ominous "Can not register twice".
DOMAIN.txt
and DOMAIN.txt,v
, and hooray:
pos@MY.DOMAIN
. But again, DOMAIN.txt
is back, with the intentionally bogus mail address I entered when registering pos@MY.DOMAIN
.
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
ItemTemplate | |
---|---|
Summary | TWikiUserMapping fails with Corporate SSO |
ReportedBy | TWiki:Main.HaraldJoerg |
Codebase | 4.2.0, ~twiki4 |
SVN Range | TWiki-4.3.0, Sun, 30 Sep 2007, build 15107 |
AppliesTo | Engine |
Component | TWikiUserMapping |
Priority | Urgent |
CurrentState | Closed |
WaitingFor | |
Checkins | TWikirev:15169 TWikirev:15170 TWikirev:15589 TWikirev:15590 TWikirev:15694 TWikirev:15695 TWikirev:15696 TWikirev:15697 TWikirev:15899 TWikirev:15900 TWikirev:15901 TWikirev:15903 TWikirev:15905 TWikirev:15906 |
TargetRelease | minor |
ReleasedIn | 4.2.0 |
I | Attachment | History | Action | Size | Date | Who | Comment |
---|---|---|---|---|---|---|---|
pm | KerberosLogin.pm | r1 | manage | 1.4 K | 2007-10-05 - 19:15 | UnknownUser | stripps off kerberos-realm |
cfg | LocalSite.cfg | r1 | manage | 8.4 K | 2007-10-06 - 22:47 | HaraldJoerg | haj's TWikiRelease04x02 SVN based configuration |