Making read-only selectively

We want to allow our TWiki to be available to internal users, using their internal login account -- and also to external users who I want to register. I have configured Apache to allow LDAP logins from internal users and from users created by the TWiki registrration via .htpasswd :

  AuthBasicProvider ldap file
  AuthLDAPURL ldap://my.ldap.server/ou=users,dc=flirble,dc=org?uid?one?
  AuthLDAPRemoteUserAttribute uid
  AuthUserFile /usr/local/www/twiki/data/.htpasswd

  AuthName 'Enter your Flirble username or WikiName: (First name and last name, no space, no dots, capitalized, e.g. JohnSmith) . Cancel to register if you do not have one.'
  AuthType Basic

To support this, I have developed a very simple User Mapping module derived from TWikiUserMapping The module maps any internal user ID (eg. jacob) to a statically derived WikiName (eg. InternalJacob), and vice verse. The module doesn't do anything for usernames that aren't internal, or for WikiNames that dont' start with "Internal". Anything it doesn't match those criteria gets passed to the parent classs (the TWikiUserMapping module ). That all works well.

I would like to complete the module by customizing the password and registration process. Obviously TWiki can't change the password of any of my internal users. So I want the password-change and registration pages/scripts to reflect this. My first attempt was an implementation of a password module. I tried to cause the readOnly() method return 0 if a username was internal.

I've had no luck with this so far because the password modules get instantiated too early to obtain the cUI of the logged in user (I think!). Can anyone think of a better way to do this?

Thanks - Jake

-- Contributors: JakeScott - 13 Aug 2008

Discussion

perhaps.

one thing is that code eventually leads to the following in TWiki::Users

    # the UI for rego supported/not is different from rego temporarily
    # turned off
    if ( $this->supportsRegistration() ) {
        $session->enterContext('registration_supported');
        $session->enterContext('registration_enabled')
          if $TWiki::cfg{Register}{EnableNewUserRegistration};
    }

That context is used later when rendering the registration and password UI's so while it will 'work' it will probably also stop you from registering new users into the .htpasswd file.

What I had envisaged was that we would write a mux mapper, that could then delegate to several other mappers - I wonder if this would help at all.

-- SvenDowideit - 13 Aug 2008

Thanks. I'll have a play with the context stuff later on.

Re. the mux mapper, I had wondered if such a thing already exists after reading the documentation for the handlesUser() method of TWiki::UserMapping :

• Called by the TWiki::Users object to determine which loaded mapping to use for a given user (must be fast).

Is the return from this ignored right now, or have I missed something important?

-- JakeScott - 13 Aug 2008

yeah TWiki::Users is a simplified mux - it mixes the BaseUserMapping and the Mapping selected in the cfg. Originally I was going to have a 'list' of configuable mappings, but this was deemed as more complex than desired - so a new MuxMapper needs to be written, at least until TWiki::Users is chnaged to support more that base plus one.

-- SvenDowideit - 13 Aug 2008