Difference: SourceCode (7 vs. 8)

[[CGISessionDotPm][]]

[[CGISessionDriverDBIDotPm][]]

[[CGISessionDriverDb_fileDotPm][]]

[[CGISessionDriverDotPm][]]

[[CGISessionDriverFileDotPm][]]

[[CGISessionDriverMysqlDotPm][]]

[[CGISessionDriverPostgresqlDotPm][]]

[[CGISessionDriverSqliteDotPm][]]

[[CGISessionErrorHandlerDotPm][]]

[[CGISessionIDIncrDotPm][]]

[[CGISessionIDMd5DotPm][]]

This package doesn't smell

[[CGISessionSerializeDefaultDotPm][]]

[[CGISessionSerializeFreezethawDotPm][]]

[[CGISessionSerializeJsonDotPm][]]

[[CGISessionSerializeStorableDotPm][]]

[[CGISessionSerializeYamlDotPm][]]

[[CGISessionTutorialDotPm][]]

[[MonitorDotPm][]]

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

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

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}

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

This package has smell factor of 1

[[TWikiFormSelectDotPm][]]

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.

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

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

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

• TOPICINFO
  • author => '...'
  • date => '...'
  • ...
• FILEATTACHMENT
  • [0] -> { name => '...' ... }
  • [1] -> { name => '...' ... }
• FIELD
  • [0] -> { name => '...' ... }
  • [1] -> { name => '...' ... }

TWiki::Net::HTTPResponse

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

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

This package doesn't smell

use Error;

...

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

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::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::UserMapping

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 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

TWiki::Users::HtPasswdUser

TWiki::Users::Password