Tags:
create new tag
, view all tags

Feature Proposal: Retaining REMOTE_USER has too many problems

Motivation

In my company's TWiki installation, we're going to be always authenticated by an external mechanism, i.e. $ENV{REMOTE_USER} has a value. TWiki mangles this value so that it passes for RCS, but I consider this broken.

Description

A user who is not registered in TWikiUsers should be treated as TWikiGuest, regardless of whether he has authenticated or not (that's again the "authentication" vs "authorization" topic).

Today, if TWiki doesn't find an entry for a login name in TWikiUsers, it creates sort of a "preliminary" wikiname from the login name by removing all unwanted characters and uses this surrogate value for all its user actions: User greeting on the left bar, signature, RCS ci invocation, ... Henceforth every action where the surrogate user name is found, even if someone just reads a page created by an unregistered user, a line about a bogus user turns up in the warnings log.

TWiki is giving the REMOTE_USER high precendence and silently assumes that a user is registered because he could login. There are always problems lurking with this approach, NumericIntranetLoginNameProblem being a recent example.

Treating unregistered users as TWikiGuest has some advantages:

  • No need to remove characters from the login name, they can be literally used and compared.
    • In my installation I have been able to disable all changes to the login name. Some care needs to be taken to prevent TWiki from interpreting login names, e.g. username@KERBEROSPLEASENOSPAM.REALM is a kerberos principal and not a mail address, so no <a href="mailto... should be created.
  • No problem with login user ids which don't fit whatever storage backend is in use. All pages saved by unregistered users appear as a work of TWikiGuest.
  • No bogus authors in TWiki's warning log and RCS entries.
  • Seeing their work signed as "Main.TWikiGuest" might motivate users to register even if they are in an authenticated environment. After all, the personal home page can deliver valuable information.

Of course, there is a disadvantage:

  • There's no hint within TWiki which of the unregistered users wrote a page. One needs to correlate RCS with the web server log (where REMOTE_USER is recorded) to differentiate between various authenticated unregistered users.

-- HaraldJoerg - 03 Nov 2005

Impact and Available Solutions

So far I have failed to create a fix which allows to consistently map any unregistered login name to TWikiGuest. There seem to be too many places in the source where an 1:1-relationship between login name and wikiname is assumed. In my company's installation I have a patch in place which simply replaces the login names of unregistered users by $cfg{DefaultUserLogin} during session initialization. This is, of course, cheating.

Documentation

Is TWikis behaviour in authenticated environments documented? I didn't find anything, and TWikiUserAuthentication is pretty short when describing the consequences of "Require login to view and edit".

Implementation

  • Map the wikiname of unregistered users to TWikiGuest even if they are carrying a REMOTE_USER.
  • Always require registration (not only authentication!) for the actions in $cfg{AuthScripts}. That's what I am currently using as a login manger (RegistrationOnDemandHack). Everyone can read like TWikiGuest, but as soon as they start editing, they need to register. However, implementing this as a login manager has drawbacks:
    • Since the login managers are enumerated in TWiki.cfg, I can't just add it like a plugin without manually changing TWiki.cfg.
    • If a user is neither authenticated nor registered, we would need authentication on demand (as it is implemented today in TWiki) and registration on demand. However, there is just one login manager configurable.
    • The verification option is ugly when used during registering on demand. You need to keep the browser window open while answering the mail.
    • The (yet unimplemented) approval option for registration is still worse.


Discussion:

I had a similar problem. I want to use basic auths to keep the Wiki private to our company in a simple way with a few generic passwords, but require real wiki logins for doing editing so we can track who did what and control access to that, something our users are used to for other tools. So I wanted it to just ignore the auth data and make the users log in via the forms, and be tracked via session cookies. It is a different solution than what this topic was looking for, but I think the overall effect is the same. With REMOTE_USER ignored, all users become guest until they login.

I found making the following edits worked. These are diffs against TWiki-4.0.1

diff original/lib/TWiki.pm new/lib/TWiki.pm 
1134c1134
<     $remoteUser ||= $query->remote_user() || $TWiki::cfg{DefaultUserLogin};
---
>     $remoteUser = $TWiki::cfg{DefaultUserLogin};
2803c2803
<     return $ENV{REMOTE_USER} || '';
---
>     return '';

diff original/bin/twiki new/bin/twiki 
92c92
< my $remoteuser = $ENV{REMOTE_USER};
---
> my $remoteuser = undef;

I also edited .htaccess to require a valid user for the view command.

It would be nice if a later version of TWiki made this hack available via a switch in the configuration script.

-- JosephAnnino - 23 Feb 2006

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r2 - 2006-02-23 - JosephAnnino
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.