Tags:
create new tag
view all tags

Feature Proposal: User mapping manager to be able to have a method to allow new web creation

Motivation

There are cases where ROOTCHANGE and ALLOWWEBCHANGE are not powerful enough to implement web creation permission you want. For example, you may want to allow a user to create a certain subweb of the web Foo while you don't want to allow to create topics on the web Foo. The way to achieve the goal efficiently is to be able to have a method in the user mapping manager allowing web creation depending on the user and the name of the web to be create.

Here are two concrete examples requiring the capability.

A large TWiki site in a large organization employing UserSubwebs

Let's assume:
  • It's about a large organization having 50,000 users in its LDAP. User IDs, real names, email addresses, etc. are in the LDAP
  • It has an intranet single sign-on mechanism leveraging the LDAP data
  • Everybody in the organization may edit topics on a TWiki site having 5,000 webs
  • The TWiki site authenticate users with the intranet single sign-on mechanism
  • UserSubwebs is in use
Implication:
  • Requiring user registration on the TWiki site for editing doesn't make a lot of sense. Because all user account data is already in LDAP, which is supposed to be referred to if needed.
  • Users need to be forbidden to create topics on the Main web. Otherwise, it accumulates a lot of clutters in the long run.
  • Users need to be able to create/delete their personal web on their own
    • Here needs an enhancement

UsingMultipleDisks and /pub/... rewritten to /cgi-bin/viewfiles/...

Let's assume:
  • There is a TWiki site employing UsingMultipleDisks
  • The HTTP server housing TWiki needs to rewrite /pub/... to /cgi-bin/viewfile/... so that all attachments are obtainable by /pub/... path without symbolic links
Implication:
  • The rewriting rule doesn't rewrite /pub/TWiki/... and /pub/Public/... so that files there can be retrieved directly (=quickly) from the HTTP server without going through TWiki.
  • For every top level web A, there can be Public/A subweb. The owner of the web A can create Public/A if they like. Web owners must not be able to create topics in Public or a subweb unrelated to web names the user owns
    • Here needs an enhancement

Description and Documentation

In TWiki::UI::Manage::_createWeb(), check if the new web is allowed to be created as follows.

unless ( $session->{users}->canCreateWeb($newWeb) ) {
    ...
    TWiki::UI::checkAccess( $session, $parent, undef, 'CHANGE', $session->{user} );
}
TWiki::Users::canCreateWeb() calls $session->{users}{mapping}->canCreateWeb($newWeb) and then returns the value if it exists. Otherwise, TWiki::Users::canCreateWeb() returns false.

There should be no need for TWiki::Users::canCreateTopic() because isAdmin() in the user mapping handler can do a similar thing with topics.

Examples

Impact

Implementation

-- Contributors: HideyoImazu - 2012-09-20

Discussion

This is now regarded as accpeted by the 7 day feedback period.

The topic title "Customizable permission to create a new web" wasn't so good. So it's now changed to "User mapping manager to be able to have a method to allow new web creation"

-- HideyoImazu - 2012-10-16

Sensible enhancement.

-- PeterThoeny - 2012-10-17

The topic name CanCreateWebMethodOfUserMappingManager was too long and has been changed to AllowWebCreateByUserMappingManager.

-- HideyoImazu - 2012-10-17

The topic name CanCreateWebMethodOfUserMappingManager sounded too conding centric. So it's renamed (again) to AllowWebCreateByUserMappingManager.

-- HideyoImazu - 2012-10-19

Edit | Attach | Watch | Print version | History: r8 < r7 < r6 < r5 < r4 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r8 - 2012-10-19 - HideyoImazu
 
  • 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-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.