Difference: SourceCode (7 vs. 8)

Revision 82008-01-22 - TWikiContributor

Line: 4 to 4
 
On this page:
Changed:
<
<

TWiki::AccessControlException

>
>

[[CGISessionDotPm][]]

 
Changed:
<
<
Exception used raise an access control violation.
>
>
This package doesn't smell
 
Added:
>
>

[[CGISessionDriverDBIDotPm][]]

 

This package doesn't smell

Changed:
<
<

TWiki::Access

>
>

[[CGISessionDriverDb_fileDotPm][]]

 
Deleted:
<
<
A singleton object of this class manages the access control database.
 
Added:
>
>
This package doesn't smell

[[CGISessionDriverDotPm][]]

 

This package doesn't smell

Changed:
<
<

TWiki::Attach

>
>

[[CGISessionDriverFileDotPm][]]

 
Deleted:
<
<
A singleton object of this class is used to deal with attachments to topics.
 
Added:
>
>
This package doesn't smell
 
Added:
>
>

[[CGISessionDriverMysqlDotPm][]]

 
Deleted:
<
<
This package has smell factor of 1
 
Changed:
<
<

TWiki::Attrs

>
>
This package doesn't smell
 
Changed:
<
<
Class of attribute sets, designed for parsing and storing attribute values from a TWiki tag e.g. %TAG{fred='bad' "sad" joe="mad"}%
>
>

[[CGISessionDriverPostgresqlDotPm][]]

 
Deleted:
<
<
An attribute set is a map containing an entry for each parameter. The default parameter (unnamed quoted string) is named _DEFAULT in the map.
 
Changed:
<
<
Attributes declared later in the string will override those of the same name defined earlier. The one exception to this is the _DEFAULT key, where the first instance of a setting is always taken.
>
>
This package doesn't smell

[[CGISessionDriverSqliteDotPm][]]

 
Deleted:
<
<
As well as standard TWiki syntax (parameter values double-quoted) it also parses single-quoted values, unquoted spaceless values, spaces around the =, and commas as well as spaces separating values, though none of these alternatives is advertised in documentation and the extended syntax can be turned off by passing the 'strict' parameter to new.
 
Changed:
<
<
This class replaces the old TWiki::extractNameValuePair and TWiki::extractParameters.
>
>
This package doesn't smell
 
Added:
>
>

[[CGISessionErrorHandlerDotPm][]]

 

This package doesn't smell

Changed:
<
<

TWiki::Client::ApacheLogin

>
>

[[CGISessionIDIncrDotPm][]]

 
Deleted:
<
<
This is login manager that you can specify in the security setup section of configure. It instructs TWiki to cooperate with your web server (typically Apache) to require authentication information (username & password) from users. It requires that you configure your web server to demand authentication for scripts named "login" and anything ending in "auth". The latter should be symlinks to existing scripts; e.g., viewauth -> view, editauth -> edit, and so on.
 
Changed:
<
<
See also TWikiUserAuthentication.
>
>
This package doesn't smell
 
Changed:
<
<
Subclass of TWiki::Client; see that class for documentation of the methods of this class.
>
>

[[CGISessionIDMd5DotPm][]]

This package doesn't smell

 
Added:
>
>

[[CGISessionSerializeDefaultDotPm][]]

 

This package doesn't smell

Changed:
<
<

TWiki::Client

>
>

[[CGISessionSerializeFreezethawDotPm][]]

 
Deleted:
<
<
The package is also a Factory for login managers and also the base class for all login managers.
 
Changed:
<
<
On it's own, an object of this class is used when you specify 'none' in the security setup section of configure. When it is used, logins are not supported. If you want to authenticate users then you should consider TemplateLogin or ApacheLogin, which are subclasses of this class.
>
>
This package doesn't smell
 
Changed:
<
<
If you are building a new login manager, then you should write a new subclass of this class, implementing the methods marked as VIRTUAL. There are already examples in the lib/TWiki/Client directory.
>
>

[[CGISessionSerializeJsonDotPm][]]

 
Deleted:
<
<
The class has extensive tracing, which is enabled by $TWiki::cfg{Trace}{Client.pm}. The tracing is done in such a way as to let the perl optimiser optimise out the trace function as a no-op if tracing is disabled.
 
Changed:
<
<
Here's an overview of how it works:
>
>
This package doesn't smell
 
Changed:
<
<
Early in TWiki::new, the login manager is created. The creation of the login manager does two things:
  1. If sessions are in use, it loads CGI::Session but doesn't initialise the session yet.
  2. Creates the login manager object
Slightly later in TWiki::new, loginManager->loadSession is called.
  1. Calls loginManager->getUser to get the username before the session is created
    • TWiki::Client::ApacheLogin looks at REMOTE_USER
    • TWiki::Client::TemplateLogin just returns undef
  2. reads the TWIKISID cookie to get the SID (or the TWIKISID parameters in the CGI query if cookies aren't available, or IP2SID mapping if that's enabled).
  3. Creates the CGI::Session object, and the session is thereby read.
  4. If the username still isn't known, reads it from the cookie. Thus TWiki::Client::ApacheLogin overrides the cookie using REMOTE_USER, and TWiki::Client::TemplateLogin always uses the session.
>
>

[[CGISessionSerializeStorableDotPm][]]

 
Deleted:
<
<
Later again in TWiki::new, plugins are given a chance to override the username found from the loginManager.
 
Changed:
<
<
The last step in TWiki::new is to find the user, using whatever user mapping manager is in place.
>
>
This package doesn't smell
 
Changed:
<
<

ObjectData twiki

>
>

[[CGISessionSerializeYamlDotPm][]]

 
Deleted:
<
<
The TWiki object this login manager is attached to.
 
Added:
>
>
This package doesn't smell
 
Added:
>
>

[[CGISessionTutorialDotPm][]]

 
Deleted:
<
<
This package has smell factor of 2
 
Changed:
<
<

TWiki::Client::TemplateLogin

>
>
This package doesn't smell
 
Changed:
<
<
This is a login manager that you can specify in the security setup section of configure. It provides users with a template-based form to enter usernames and passwords, and works with the PasswordManager that you specify to verify those passwords.
>
>

[[MonitorDotPm][]]

 
Deleted:
<
<
Subclass of TWiki::Client; see that class for documentation of the methods of this class.
 
Added:
>
>
This package doesn't smell
 
Added:
>
>

TWiki::AccessControlException

Exception used raise an access control violation. This exception has the following fields:

  • web - the web which was being accessed
  • topic - the topic being accessed (if any)
  • user - canonical username of the person doing the accessing. Use the methods of the TWiki::Users class to get more information about the user.
  • mode - the access mode e.g. CHANGE, VIEW etc
  • reason a text string giving the reason for the refusal.

The exception may be thrown by plugins. If a plugin throws the exception, it will normally be caught and the browser redirected to a login screen (if the user is not logged in) or reported (if they are and just don't have access).

This package doesn't smell

TWiki::Access

A singleton object of this class manages the access control database.

This package doesn't smell

TWiki::AggregateIterator

combine multiple iterators

 
Changed:
<
<
This package has smell factor of 1
>
>

This package doesn't smell

TWiki::Attach

A singleton object of this class is used to deal with attachments to topics.

This package doesn't smell

TWiki::Attrs

Class of attribute sets, designed for parsing and storing attribute values from a TWiki tag e.g. %TAG{"joe" fred="bad" joe="mad"}%

An attribute set is a hash containing an entry for each parameter. The default parameter (unnamed quoted string) is named _DEFAULT in the hash.

Attributes declared later in the string will override those of the same name defined earlier. The one exception to this is the _DEFAULT key, where the first instance is always taken.

As well as the default TWiki syntax (parameter values double-quoted) this class also parses single-quoted values, unquoted spaceless values, spaces around the =, and commas as well as spaces separating values. The extended syntax has to be enabled by passing the $friendly parameter to new.

This package doesn't smell

 

TWiki::Compatibility

Line: 169 to 197
 Global variables are avoided wherever possible to avoid problems with CGI accelerators such as mod_perl.
Added:
>
>

Public Data members

  • cgiQuery Pointer to the CGI::
  • context Hash of context ids
  • moved: loginManager TWiki::LoginManager singleton (moved to TWiki::Users)
  • plugins TWiki::Plugins singleton
  • prefs TWiki::Prefs singleton
  • remoteUser Login ID when using ApacheLogin. Maintained for compatibility only, do not use.
  • requestedWebName Name of web found in URL path or web URL parameter
  • sandbox TWiki::Sandbox singleton
  • scriptUrlPath URL path to the current script. May be dynamically extracted from the URL path if {GetScriptUrlFromCgi}. Only required to support {GetScriptUrlFromCgi} and not consistently used. Avoid.
  • security TWiki::Access singleton
  • SESSION_TAGS Hash of TWiki variables whose value is specific to the current CGI request.
  • store TWiki::Store singleton
  • topicName Name of topic found in URL path or topic URL parameter
  • urlHost Host part of the URL (including the protocol) determined during intialisation and defaulting to {DefaultUrlHost}
  • user Unique user ID of logged-in user
  • users TWiki::Users singleton
  • webName Name of web found in URL path, or web URL parameter, or {UsersWebName}
 
Changed:
<
<
This package has smell factor of 25
>
>
This package has smell factor of 32
 

TWiki::Form

Object representing a single form definition.

Added:
>
>
Form definitions are mainly used to control rendering of a form for editing, though there is some application login there that handles transferring values between edits and saves.

A form definition consists of a TWiki::Form object, which has a list of field definitions. Each field definition is an object of a type derived from TWiki::Form::FieldDefinition. These objects are responsible for the actual syntax and semantics of the field type. Form definitions are parsed from TWiki tables, and the types are mapped by name to a class declared in TWiki::Form::* - for example, the text type is mapped to TWiki::Form::Text and the checkbox type to TWiki::Form::Checkbox.

The TWiki::Form::FieldDefinition class declares default behaviours for types that accept a single value in their definitions. The TWiki::Form::ListFieldDefinition extends this for types that have lists of possible values.

This package has smell factor of 4

TWiki::Form::FieldDefinition

Base class of all field definition classes.

Type-specific classes are derived from this class to define specific per-type behaviours. This class also provides default behaviours for when a specific type cannot be loaded.

This package doesn't smell

TWiki::Form::ListFieldDefinition

Form field definitions that accept lists of values in the field definition. This is different to being multi-valued, which means the field type can store multiple values.

This package has smell factor of 1

[[TWikiFormSelectDotPm][]]

 
Changed:
<
<
This package has smell factor of 9
>
>
This package doesn't smell
 

TWiki::Func

Line: 188 to 287
  Official list of stable TWiki functions for Plugin developers
Changed:
<
<
This module defines official functions that Plugins
>
>
This module defines official functions that Plugins
 can use to interact with the TWiki engine and content.

Refer to EmptyPlugin and lib/TWiki/Plugins/EmptyPlugin.pm for a template Plugin and documentation on how to write a Plugin.

Line: 203 to 302
  The version of the TWiki::Func module is defined by the VERSION number of the TWiki::Plugins module, currently 6.02. This can be shown
Changed:
<
<
by the %PLUGINVERSION% variable. The 'Since' field in the function documentation refers to the VERSION number and the date that the function was addded.

Note: Beware! These methods should only ever be called from the context of a TWiki Plugin. They require a Plugins SESSION context to be established before they are called, and will not work if simply called from another TWiki module. For example,

use TWiki;
print TWiki::Func::getSkin(),"\n";
will fail with Can't call method "getSkin" on an undefined value at TWiki/Func.pm line 83.

If you want to call the methods outside the context of a plugin, you can create a Plugins SESSION object. For example, the script:

use TWiki:
$TWiki::Plugins::SESSION = new TWiki();
print TWiki::Func::getSkin(),"\n";
will work happily.
>
>
by the %PLUGINVERSION% TWiki variable, and accessed in code using $TWiki::Plugins::VERSION. The 'Since' field in the function documentation refers to $TWiki::Plugins::VERSION.

Notes on use of $TWiki::Plugins::VERSION (from 1.2 forwards):

  • If the major version (e.g. 1.) is the same then any plugin coded to use any earlier revision of the 1. API will still work. No function has been removed from the interface, nor has any API published in that version changed in such a way as to require plugins to be recoded.
  • If the minor version (e.g. 1.1) is incremented there may be changes in the API that may help improve the coding of some plugins - for example, new interfaces giving access to previously hidden core functions. In addition, deprecation of functions in the interface trigger a minor version increment. Note that deprecated functions are not removed, they are merely frozen, and plugin authors are recommended to stop using them.
  • Any additional digits in the version number relate to minor changes, such as the addition of parameters to the existing functions, or addition of utility functions that are unlikely to require significant changes to existing plugins.
  • TWiki::Plugins::VERSION also applies to the plugin handlers. The handlers are documented in the EmptyPlugin, and that module indicates what version of TWiki::Plugins::VERSION it relates to.
A full history of the changes to this API can be found at the end of this topic.
 
Line: 247 to 349
  This package has smell factor of 1
Changed:
<
<

TWiki::If

>
>

TWiki::If::Node

Node class for the result of an If statement parse

This package doesn't smell

TWiki::If::Parser

Support for the conditions in %IF{} statements.

This package doesn't smell

TWiki::Infix::Error

Class of errors used with TWiki::Infix::Parser

This package doesn't smell

TWiki::Infix::Node

Base class for node types generated by Infix::Parser. You don't have to use it, but it may be useful.

This package doesn't smell

TWiki::Infix::Parser

A simple stack-based parser that parses infix expressions with nonary, unary and binary operators specified using an operator table.

Escapes are supported in strings, using backslash.

This package doesn't smell

TWiki::LineIterator

Iterator over the lines in a file

This package doesn't smell

TWiki::ListIterator

 
Changed:
<
<
Support for the conditions in %IF{} statements. Basically a simple stack-based parser for infix expressions that generates a parse tree that can subsequently be evaluated.
>
>
Iterator over a list
 

This package doesn't smell

Added:
>
>

TWiki::LoginManager::ApacheLogin

This is login manager that you can specify in the security setup section of configure. It instructs TWiki to cooperate with your web server (typically Apache) to require authentication information (username & password) from users. It requires that you configure your web server to demand authentication for scripts named "login" and anything ending in "auth". The latter should be symlinks to existing scripts; e.g., viewauth -> view, editauth -> edit, and so on.

See also TWikiUserAuthentication.

Subclass of TWiki::LoginManager; see that class for documentation of the methods of this class.

This package has smell factor of 1

TWiki::LoginManager

The package is also a Factory for login managers and also the base class for all login managers.

On it's own, an object of this class is used when you specify 'none' in the security setup section of configure. When it is used, logins are not supported. If you want to authenticate users then you should consider TemplateLogin or ApacheLogin, which are subclasses of this class.

If you are building a new login manager, then you should write a new subclass of this class, implementing the methods marked as VIRTUAL. There are already examples in the lib/TWiki/LoginManager directory.

The class has extensive tracing, which is enabled by $TWiki::cfg{Trace}{LoginManager.pm}. The tracing is done in such a way as to let the perl optimiser optimise out the trace function as a no-op if tracing is disabled.

Here's an overview of how it works:

Early in TWiki::new, the login manager is created. The creation of the login manager does two things:

  1. If sessions are in use, it loads CGI::Session but doesn't initialise the session yet.
  2. Creates the login manager object
Slightly later in TWiki::new, loginManager->loadSession is called.
  1. Calls loginManager->getUser to get the username before the session is created
    • TWiki::LoginManager::ApacheLogin looks at REMOTE_USER (only for authenticated scripts)
    • TWiki::LoginManager::TemplateLogin just returns undef
  2. reads the TWIKISID cookie to get the SID (or the TWIKISID parameters in the CGI query if cookies aren't available, or IP2SID mapping if that's enabled).
  3. Creates the CGI::Session object, and the session is thereby read.
  4. If the username still isn't known, reads it from the cookie. Thus TWiki::LoginManager::ApacheLogin overrides the cookie using REMOTE_USER, and TWiki::LoginManager::TemplateLogin always uses the session.

Later again in TWiki::new, plugins are given a chance to override the username found from the loginManager.

The last step in TWiki::new is to find the user, using whatever user mapping manager is in place.

ObjectData twiki

The TWiki object this login manager is attached to.

This package has smell factor of 7

TWiki::LoginManager::TemplateLogin

This is a login manager that you can specify in the security setup section of configure. It provides users with a template-based form to enter usernames and passwords, and works with the PasswordManager that you specify to verify those passwords.

Subclass of TWiki::LoginManager; see that class for documentation of the methods of this class.

This package has smell factor of 2

 

TWiki::Merge

Support for merging strings

Line: 267 to 497
 

TWiki::Meta

Changed:
<
<
Meta-data handling.
>
>
All TWiki topics have data (text) and meta-data (information about the topic). Meta-data includes information such as file attachments, form fields, topic parentage etc. When TWiki loads a topic from the store, it represents the meta-data in the topic using an object of this class.
  A meta-data object is a hash of different types of meta-data (keyed on the type, such as 'FIELD' and 'TOPICINFO').
Line: 277 to 510
 single meta-datum.

If there may be multiple entries of the same top-level type (i.e. for FIELD

Changed:
<
<
and FILEATTACHMENT) then the array hash multiple entries. These types
>
>
and FILEATTACHMENT) then the array has multiple entries. These types
 are referred to as "keyed" types. The array entries are keyed with the attribute 'name' which must be in each entry in the array.

For unkeyed types, the array has only one entry.

Changed:
<
<
The module knows nothing about how meta-data is stored. That is entirely the responsibility of the Store module.
>
>
Pictorially,
  • TOPICINFO
    • author => '...'
    • date => '...'
    • ...
  • FILEATTACHMENT
    • [0] -> { name => '...' ... }
    • [1] -> { name => '...' ... }
  • FIELD
    • [0] -> { name => '...' ... }
    • [1] -> { name => '...' ... }
 
Changed:
<
<
Meta-data objects are created by the Store engine when topics are read. They are populated using the put method.
>
>
As well as the meta-data, the object also stores the web name, topic name and remaining text after meta-data extraction.
 
Changed:
<
<
This package has smell factor of 3
>
>
This package has smell factor of 2
 

TWiki::Net

Line: 299 to 541
 
Changed:
<
<
This package has smell factor of 2
>
>
This package has smell factor of 3

TWiki::Net::HTTPResponse

Fakeup of HTTP::Response for use when LWP is not available. Only implements a small subset of the HTTP::Response methods:

code()
message()
header($field)
content()
is_error()
is_redirect()

See the documentation of HTTP::Response for information about the methods.

This package doesn't smell

 

TWiki::OopsException

Line: 304 to 563
 

TWiki::OopsException

Exception used to raise a request to redirect to an Oops URL.

Added:
>
>
 An OopsException thrown anywhere in the code will redirect the
Changed:
<
<
browser to a url based on the oops script. oops requires a template parameter, that is the name of a template file from the templates directory. This file will be expanded and the
>
>
browser to a url based on the oops script. oops requires the name of an oops template file from the templates directory. This file will be expanded and the
 parameter values passed to the exception instantiated. The result will be shown in the browser.
Added:
>
>
Plugins may throw TWiki::OopsException. For example:

use Error;

...

throw TWiki::OopsException( 'bathplugin',
                            def => 'toestuck',
                            web => $web,
                            topic => $topic,
                            params => [ 'bigtoe', 'hot tap' ] );
 

This package doesn't smell

Line: 397 to 670
  This package doesn't smell
Added:
>
>

TWiki::Query::HoistREs

Static functions to extract regular expressions from queries. The REs can be used in caching stores that use the TWiki standard inline meta-data representation to pre-filter topic lists for more efficient query matching.

See Store/RcsFile.pm for an example of usage.

This package doesn't smell

TWiki::Query

A Query object is a representation of a query over the TWiki database.

Fields are given by name, and values by strings or numbers. Strings should always be surrounded by 'single-quotes'. Numbers can be signed integers or decimals. Single quotes in values may be escaped using backslash (\).

See QuerySearch for details of the query language. At the time of writing only a subset of the entire query language is supported, for use in searching.

A query object implements the evaluate method as its general contract with the rest of the world. This method does a "hard work" evaluation of the parser tree. Of course, smarter Store implementations should be able to do it better....

This package has smell factor of 2

TWiki::Query::Parser

Parser for queries

This package doesn't smell

 

TWiki::Render

This module provides most of the actual HTML rendering code in TWiki.

Changed:
<
<
This package has smell factor of 19
>
>
This package has smell factor of 20
 

TWiki::Sandbox

Line: 411 to 722
 system functions, or handling of file names, should be brokered by this object.
Added:
>
>
NOTE: TWiki creates a singleton sandbox that is shared by all TWiki runs under a single mod_perl instance. If any TWiki run modifies the sandbox, that modification will carry over in to subsequent runs. Be very, very careful!
 
Changed:
<
<
This package has smell factor of 3
>
>
This package has smell factor of 4
 

TWiki::Search

Line: 421 to 737
 
Changed:
<
<
This package has smell factor of 20
>
>
This package has smell factor of 15
 

TWiki::Store

Line: 441 to 757
 
Changed:
<
<
This package has smell factor of 17
>
>
This package has smell factor of 14

TWiki::Store::QueryAlgorithms::BruteForce

Default brute-force query algorithm

Has some basic optimisation: it hoists regular expressions out of the query to use with grep, so we can narrow down the set of topics that we have to evaluate the query on.

Not sure exactly where the breakpoint is between the costs of hoisting and the advantages of hoisting. Benchmarks suggest that it's around 6 topics, though this may vary depending on disk speed and memory size. It also depends on the complexity of the query.

This package doesn't smell

 

TWiki::Store::RcsFile

This class is PACKAGE PRIVATE to Store, and should never be

Changed:
<
<
used from anywhere else. Base class of implementations of stores
>
>
used from anywhere else. It is the base class of implementations of stores
 that manipulate RCS format files.

The general contract of the methods on this class and its subclasses

Line: 456 to 789
 
Changed:
<
<
This package has smell factor of 9
>
>
This package has smell factor of 11
 

TWiki::Store::RcsLite

Line: 553 to 886
 
Changed:
<
<
This package has smell factor of 2
>
>
This package has smell factor of 3
 

TWiki::Store::SearchAlgorithms::Forking

Forking implementation of the RCS cache search.

search($searchString, $topics, $options, $sDir) -> \%seen

Changed:
<
<
Search .txt files in $dir for $string. See RcsFile::searchInWebContent
>
>
Search .txt files in $dir for $searchString. See RcsFile::searchInWebContent
 for details.

Changed:
<
<
This package has smell factor of 2

TWiki::Store::SearchAlgorithms::Native

Native implementation of the RCS cache search. Requires tools/native_search to be built and installed.

search($searchString, $topics, $options, $sDir) -> \%seen

Search .txt files in $dir for $string. See RcsFile::searchInWebContent for details.

Rude and crude, this makes no attempt to handle UTF-8.

This package doesn't smell

>
>
This package has smell factor of 1
 

TWiki::Store::SearchAlgorithms::PurePerl

Line: 664 to 982
 
Changed:
<
<
This package has smell factor of 19
>
>
This package has smell factor of 5
 

TWiki::UI::Save

Line: 680 to 998
 
Changed:
<
<
This package has smell factor of 3
>
>
This package has smell factor of 2
 

TWiki::UI::Statistics

Line: 706 to 1024
  This package has smell factor of 2
Changed:
<
<

TWiki::User

>
>

TWiki::UserMapping

 
Changed:
<
<
A User object is an internal representation of a user in the real world. The object knows about users having login names, wiki names, personal topics, and email addresses.
>
>
This is a virtual base class (a.k.a an interface) for all user mappers. It is not useable as a mapping in TWiki - use the BaseUserMapping for default behaviour.
 
Added:
>
>
User mapping is the process by which TWiki maps from a username (a login name) to a display name and back. It is also where groups are maintained.
 
Added:
>
>
See TWiki::Users::BaseUserMapping and TWiki::Users::TWikiUserMapping for the default implementations of this interface.
 
Changed:
<
<
This package has smell factor of 4
>
>
If you want to write a user mapper, you will need to implement the methods described in this class.

User mappings work by mapping both login names and display names to a canonical user id. This user id is composed from a prefix that defines the mapper in use (something like 'BaseUserMapping_' or 'LdapUserMapping_') and a unique user id that the mapper uses to identify the user.

The null prefix is reserver for the TWikiUserMapping for compatibility with old TWiki releases.

Note: in all the following documentation, $user refers to a canonical user id.

This package has smell factor of 1

 

TWiki::Users::ApacheHtpasswdUser

Line: 729 to 1067
 
Changed:
<
<
This package doesn't smell
>
>
This package has smell factor of 1
 

TWiki::Users

Added:
>
>
This package provides services for the lookup and manipulation of login and wiki names of users, and their authentication.
 
Changed:
<
<
Singleton object that handles mapping of users to wikinames and vice versa, and user authentication checking.
>
>
It is a Facade that presents a common interface to the User Mapping and Password modules. The rest of the core should only use the methods of this package, and should never call the mapping or password managers directly.

TWiki uses the concept of a login name which is used to authenticate a user. A login name maps to a wiki name that is used to identify the user for display. Each login name is unique to a single user, though several login names may map to the same wiki name.

Using this module (and the associated plug-in user mapper) TWiki supports the concept of groups. Groups are sets of login names that are treated equally for the purposes of access control. Group names do not have to be wiki names, though it is helpful for display if they are.

Internally in the code TWiki uses something referred to as a _canonical user id_ or just user id. The user id is also used externally to uniquely identify the user when (for example) recording topic histories. The user id is usually just the login name, but it doesn't need to be. It just has to be a unique 7-bit alphanumeric and underscore string that can be mapped to/from login and wiki names by the user mapper.

The canonical user id should never be seen by a user. On the other hand, core code should never use anything but a canonical user id to refer to a user.

Terminology

  • A login name is the name used to log in to TWiki. Each login name is assumed to be unique to a human. The Password module is responsible for authenticating and manipulating login names.
  • A canonical user id is an internal TWiki representation of a user. Each canonical user id maps 1:1 to a login name.
  • A wikiname is how a user is displayed. Many user ids may map to a single wikiname. The user mapping module is responsible for mapping the user id to a wikiname.
  • A group id represents a group of users and other groups. The user mapping module is responsible for mapping from a group id to a list of canonical user ids for the users in that group.
  • An email is an email address asscoiated with a login name. A single login name may have many emails.

NOTE:

  • wherever the code references $user, its a canonical_id
  • wherever the code references $group, its a group_name
 
Deleted:
<
<
This package has smell factor of 2

TWiki::Users::Password

Base class of all password handlers. Default behaviour is no passwords, so anyone can be anyone they like.

The methods of this class should be overridded by subclasses that want to implement other password handling methods.

 
Added:
>
>
This package has smell factor of 5
 
Added:
>
>

TWiki::Users::HtPasswdUser

 
Changed:
<
<
This package has smell factor of 1
>
>
Support for htpasswd and htdigest format password files.
 
Changed:
<
<

TWiki::Users::TWikiUserMapping

>
>
Subclass of TWiki::Users::Password . See documentation of that class for descriptions of the methods of this class.
 
Deleted:
<
<
User mapping is the process by which TWiki maps from a username (a login name) to a wikiname and back. It is also where groups are maintained.
 
Deleted:
<
<
By default TWiki maintains user topics and group topics in the Main that define users and group. These topics are
  • TWikiUsers - stores a mapping from usernames to TWiki names
  • WikiName - for each user, stores info about the user
  • GroupNameGroup - for each group, a topic ending with "Group" stores a list of users who are part of that group.
 
Changed:
<
<
Many sites will want to override this behaviour, for example to get users and groups from a corporate database.
>
>
This package has smell factor of 3
 
Changed:
<
<
This class implements the basic TWiki behaviour using topics to store users, but is also designed to be subclassed so that other services can be used.
>
>

TWiki::Users::Password

 
Changed:
<
<
Subclasses should be named 'XxxxUserMapping' so that configure can find them.
>
>
Base class of all password handlers. Default behaviour is no passwords, so anyone can be anyone they like.
 
Changed:
<
<
All methods in this class should be implemented by subclasses.
>
>
The methods of this class should be overridded by subclasses that want to implement other password handling methods.
 
Changed:
<
<
This package has smell factor of 3
>
>
This package doesn't smell
 
Changed:
<
<
There were a total of 200 smells
>
>
There were a total of 192 smells
 
This site is powered by the TWiki collaboration platform Powered by PerlCopyright © 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
Note: Please contribute updates to this topic on TWiki.org at TWiki:TWiki.SourceCode.