-
plone.resource-1.0.2-1.lbn13.noarch
plone.resource publishes directories of static files via the ZPublisher. These directories may be located either in the ZODB (as OFS folders and files), or on the filesystem.
Each resource directory has a type and a name. When combined, these are used to traverse to the resource directory. For example:
/++theme++mytheme/<subpath>
/++sitelayout++mylayout/<subpath>
/++templatelayout++mylayout<subpath>
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.resourceeditor-1.0-1.lbn13.noarch
This package contains resources for integrating ACE (http://ace.ajax.org/) into Plone, with a file manager that can edit plone.resource resource directories in the ZODB.
ACE can be found under ++resource++plone.resourceeditor/ace/*.
The file manager can be included in a view with the following in the header:
<metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/resources" />
and the following in the body:
<metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/filemanager">
In both of these cases, resourceDirectory should be an in-ZODB plone.resource resource directory instance.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.rfc822-1.1-1.lbn13.noarch
This package provides primitives for turning content objects described by zope.schema
fields into RFC (2)822 style messages, as managed by the Python standard library's
email module.
It consists of:
* A marker interface IPrimaryField which can be used to indicate the primary field
of a schema. The primary field will be used as the message body.
* An interface IFieldMarshaler which describes marshalers that convert to and from
strings suitable for encoding into an RFC 2822 style message. These are adapters
on (context, field), where context is the content object and field is the schema
field instance.
* Default implementations of IFieldMarshaler for the standard fields in the
zope.schema package.
* Helper methods to construct messages from one or more schemata or a list of
fields, and to parse a message and update a context object accordingly.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.scale-1.3.3-1.lbn13.noarch
Image scaling
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.schemaeditor-1.3.5-1.lbn13.noarch
plone.schemaeditor provides a through-the-web interface for modifying Zope 3 schemata (interfaces).
Currently there is support for:
* adding and removing fields
* editing attributes of existing fields
* reordering fields
* renaming fields
plone.schemaeditor only handles the actual schema editing. To be useful, it requires some integration code to take care of the following pieces:
* traversing to a schema that is used as the context of the editor
* persisting schema changes across Zope restarts
See plone.app.dexterity (along with plone.dexterity and plone.supermodel) for one approach to this integration.
The following field types (from zope.schema) are currently supported:
* TextLine
* Text
* Int
* Float
* Bool
* Password
* Datetime
* Choice (with simple list of values)
* List of Choice (with simple list of values)
Third-party packages can make additional field types available by registering new IFieldFactory utilities.
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.session-3.5.3-1.lbn13.noarch
plone.session implements secure session management for Zope sites. It
can be used directly, or be used as a base for custom session management
strategies.
In its default configuration plone.sessions uses a secure cryptographic
hash based on HMAC_ SHA-1_ to authenticate sessions. The hash is generated
using the users login name and a secret stored in the PAS plugin. This has
several advantages over other session management systems:
* passwords are not send to the server in a cookie on every request, as
is done by the *Cookie Auth Helper*
* it does not require any ZODB write for sessions, as is needed by the
*Session Crumbler*. This allows it to scale very well.
* it allows you to invalidate all existing authentication cookies for
users by updating the secret.
Normally a session cookie is used to track sessions; that means that as long as
a user keeps his browser open (and does not explicitly log out) the session
remains opens. This can be changed by setting the ``cookie_lifetime`` property
of the plugin to the number of seconds the cookie should remain valid *after
the moment of login*.
Using plone.session
-------------------
plone.session only takes care of handling sessions for already authenticated
users. This means it can not be used stand-alone: you need to have another
PAS plugin, such as the standard *Cookie Auth Helper* to take care of
authentication.
After a user has been authenticated plone.session can take over via the
PAS *credentials update* mechanism.
Using custom session authentication
-----------------------------------
plone.session delegates the generation and verification of sessions to
an ISessionSource adapter. This adapter adapts the PAS plugin and
implements four methods:
createIdentifier
Return an identifier for a userid. An identifier is a standard python
string object.
verifyIdentifier
Verify if an identity corresponds to a valid session. Returns
a boolean indicating if the identify is valid.
extractLoginName
Extract the login name from an identifier.
invalidateSession
Mark a session for a principal as invalid. A source may not support this,
in which case it should return False.
plone.session ships with two example adapers: hash and userid.
The userid adapter is a trivial example which uses the userid as session
identifier. This is very insecure since there is no form of verification at
all. DO NOT USE THIS ADAPTER IN YOUR SITE!
The hash plugin creates a random secret string which is stored as an attribute
on your plugin. It uses this secret to create a SHA1 signature for the user id
with the secret as session identifier. This approach has several good qualities:
* it allows us to verify that a session identifier was created by this site
* there is no need to include passwords in the session idenfitier
* it does not need to store anything in Zope itself. This means it works
as-is in ZEO setups and can scale very well.
There are a few downsides to this approach:
* if a users password is changed or disabled session identifiers will continue
to work, making it hard to lock out users
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.stringinterp-1.0.11-1.lbn13.noarch
Adaptable string interpolation
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.subrequest-1.6.7-2.lbn13.noarch
Subrequests for Zope2
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.supermodel-1.2.4-1.lbn13.noarch
Integration layer making it possible to load schema definitions from XML
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13
-
plone.synchronize-1.0.1-2.lbn13.noarch
Simple decorators to support synchronized methods
Located in
LBN
/
…
/
Plone and Zope
/
BastionLinux 13