create new tag
, view all tags

A different approach for TWikiUsers

TWikiUsers is inherently dependent on the content of other pages. As such it should be generated dynamically. ReplaceAllUsersPage suggested replacing it with a search, but Peter pointed out that such a search (implemented in Dakar as UserList) cannot aggregate the login names as the WikiName <-> LoginName mapping is stored on TWikiUsers.

Can LoginNames be stored alongside email addresses in the internal file? (.htpasswd where that's used). It has to be in sync with that file anyway so it might as well be in that file.

Either that or has anyone written a tool to regenerate a missing TWikiUsers file (sans loginnames of course).

-- Contributors: MartinCleaver


-- MartinCleaver - 02 Mar 2006

And how will that work with e.g. an LDAP authentication situation?

Here you have no .htpasswd file. And you normally have both login name and WikiName.

-- KennethLavrsen - 02 Mar 2006

Once again, this would be a perfect use for DynamicDataSets. Then we could cache the search and be able to use that list further processing.

-- LynnwoodBrown - 02 Mar 2006

> And how will that work with e.g. an LDAP authentication situation?

It is the responsibility of the password manager, which happens to store the data in .htpasswd where there is one.

-- MartinCleaver - 04 Mar 2006

This is something I considered when I was adding the email storage. I thought of adding key-value pairs to the .htpasswd info field for this purpose. In the end i didn't, because I was pressed for time, and didn;t want to raise the risk. However it makes perfect sense to do so. It just takes someone to work out a sensible user info API etc. (which can be independent of the actual stored content).

-- CrawfordCurrie - 06 Mar 2006

The Login/Wikiname mapping needs to be done somewhere for sites that use external auth (e.g. do not have a local .htaccess file). An administrator needs to be able to fix the list easily, which is possible with the current TWikiUsers topic approach. It could be taken out of band if (1) the audit trail is done, (2) the list can be mainatined easily using a browser.

-- PeterThoeny - 06 Mar 2006

Side note: There has never beeen an audit trail of changes to .htpasswd, nor a method to maintain it through the browser.

-- MartinCleaver - 07 Mar 2006

The TWikiUsers approach was a good one for the problem it solved: login managed by the apache server, login names potentially being dictated by an auth server, etc. But with more authentication methods being required, it is running out of steam.

Dakar supports pluggable password managers. A password manager is an interface which provides services for the management of users and groups. All potentially sensitive information about a user, and any information that needs ot be shared with other applications, needs to be managed by the password manager. A password manager implementation might choose to store that information in a topic, but it must not be required to do it that way.

For example, consider an environment where an LDAP server provides user identity services. At the moment, the only way to handle logins with LDAP is to use mod_auth_ldap. That's fine as far as it goes, but it then requires the mapping to the wikiname to be stored in TWikiUsers. Worse, it requires the duplication of all the user records that LDAP stores in TWiki; email, photograph, etc etc all have to be duplicated in TWiki, because TWiki has no way of performing additional LDAP queries to get that info.

If instead TemplateLogin is used and an LDAP password manager is implemented, the password manager can handle all these queries, meaning that TWiki not only no longer needs TWikiUsers, it doesn't even need user topics either.

So think about the current implementation as being "just one way to do it". It's perfectly valid, but it's specific to one password manager implementation, and should not be a requirement on all others.

Maintenance of users/passwords in any password manager of course depends on the services offered by the password manager. The browser interface to those management functions is a separate issue; it is general to all password managers.

On the audit trail point; that's a good selling point for a password manager implementation, but should not be perceived as a requirement.

-- CrawfordCurrie - 07 Mar 2006

https://docs.indymedia.org/view/Sysadmin/ImcDocsAdminTips offers:

cat ../.htpasswd | sed -e 's/^/ * /' | sed -e "s/:.*$//" | sort | sed -e 's/$/\n/' > TWikiUsers.txt

To regenerate the file in the event of loss.

-- MartinCleaver - 09 Oct 2006

and If you want to be really clever about it, you could codeify that into a new UserMapper.pm that overrides TWiki's default behaiviour smile

-- SvenDowideit - 09 Oct 2006

In the meantime, this works better:

cat .htpasswd | sort | perl -pe 's/^(.*):.*:.*/ \* $1 - $1 - 10 Oct 2006 \n/' > Main/TWikiUsers.txt

-- MartinCleaver - 10 Oct 2006

The form outputted by this last variant generates the output in a form that can be then be input to the non-intention-revealing-named upgrade_emails.pl

-- MartinCleaver - 10 Oct 2006

Edit | Attach | Watch | Print version | History: r11 < r10 < r9 < r8 < r7 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r11 - 2006-10-10 - MartinCleaver
  • 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.