Modified items

All recently modified items, latest first.

plone.synchronize-1.0.1-2.lbn13.noarch: Simple decorators to support synchronized methods

plone.supermodel-1.2.4-1.lbn13.noarch: Integration layer making it possible to load schema definitions from XML

plone.subrequest-1.6.7-2.lbn13.noarch: Subrequests for Zope2

plone.stringinterp-1.0.11-1.lbn13.noarch: Adaptable string interpolation

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

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.

plone.scale-1.3.3-1.lbn13.noarch: Image scaling

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.

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.

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>

plone.reload-2.0-2.lbn13.noarch: While being logged into the ZMI as an user with the Manager role visit /@@reload on your Zope application root via a browser. If your Zope is configured to listen on port 8080 on localhost this is: http://localhost:8080/@@reload If you get a Resource not found error, make sure you have loaded the configure.zcml file from this library and you really use the ZODB application root and not a Plone site as the base url. When you press the Reload Code button, all modules that have been changed since the last time they were loaded are reloaded. You'll get a status message telling you which modules have been reloaded. To reload all ZCML without a restart, press the 'Reload Code and ZCML' button. The action to perform is determined via a simple query string, so once you did a 'Reload Code' once, you can simply reload the browser page to execute the action once again. Caveats: There's some code structures which cannot be reloaded via the approach underlying this library. Plone portlets and content types are two examples of this. In general decorators will currently not always work.

plone.registry-1.0.1-1.lbn13.noarch: A debconf-like (or about:config-like) registry for storing application settings

plone.recipe.zope2zeoserver-1.4-3.lbn13.noarch: This recipe creates and configures a Zope 2 ZEO server in parts. It also installs a control script, which is like zeoctl, in the bin/ directory. The name of the control script is the the name of the part in buildout. You can use it with a part like this:: [zeoserver] recipe = plone.recipe.zope2zeoserver zope2-location = /path/to/zope2/install zeo-address = 8100 Options ------- zope2-location The path where Zope 2 is installed. If you are also using the plone.recipe.zope2install recipe, and you have that configured as a part called 'zope2' prior to the zope2zeoserver part, you can use ${zope2:location} for this parameter. You must ensure the zope2zeoserver part is run *after* the zope2install one. zeopack The path to the zeopack.py backup script. A wrapper for this will be generated in bin/zeopack, which sets up the appropriate environment to run this. Defaults to "${zope2-location}/utilities/ZODBTools/zeopack.py". Set this option to an empty value if you do not want this script to be generated. repozo The path to the repozo.py backup script. A wrapper for this will be generated in bin/repozo, which sets up the appropriate environment for running this. Defaults to "${zope2-location}/utilities/ZODBTools/repozo.py". Set this to an empty value if you do not want this script to be generated. zeo-conf A relative or absolute path to a zeo.conf file. If this is not given, a zeo.conf will be generated based on the the options below. The following options all affect the generated zope.conf. zeo-address Give a port for the ZEO server (either specify the port number only (with 'localhost' as default) or you use the format ``host:port``). Defaults to 8100. effective-user The name of the effective user for the ZEO process. Defaults to not setting an effective user. invalidation-queue-size The invalidation-queue-size used for the ZEO server. Defaults to 100. zeo-log The filename of the ZEO log file. Defaults to var/log/${partname}.log zeo-log-format Format of logfile entries. Defaults to %(asctime)s %(message)s zeo-log-custom A custom section for the eventlog, to be able to use another event logger than `logfile`. `zeo-log` is still used to set the logfile value in the runner section. storage-number The number used to identify a storage. file-storage The filename where the ZODB data file will be stored. Defaults to var/filestorage/Data.fs. blob-storage The folder where the ZODB blob data files will be stored. socket-name The filename where ZEO will write its socket file. Defaults to var/zeo.zdsock. authentication-database The filename for a authentication database. Only accounts listed in this database will be allowed to access the ZEO server. The format of the database file is:: realm <realm> <username>:<hash> Where the hash is generated via:: import sha string = "%s:%s:%s" % (username, realm, password) sha.new(string).hexdigest() authentication-realm The authentication realm. Defaults to 'ZEO' pack-days Specify of days for the zeopack script to retain of history. Defaults to one day. pack-user If the ZEO server uses authentication, this is the username used by the zeopack script to connect to the ZEO server. pack-password If the ZEO server uses authentication, this is the password used by the zeopack script to connect to the ZEO server. zeo-conf-additional Give additional lines to zeo.conf. Make sure you indent any lines after the one with the parameter. monitor-address The address at which the monitor server should listen. The monitor server provides server statistics in a simple text format. relative-paths Set this to `true` to make the generated scripts use relative paths. You can also enable this in the `[buildout]` section.

plone.recipe.zope2instance-4.2.13-1.lbn13.noarch: This recipe creates and configures a Zope 2 instance in parts. It also installs a control script, which is like zopectl, in the bin/ directory. The name of the control script is the the name of the part in buildout. You can use it with a part like this:: [instance] recipe = plone.recipe.zope2instance zope2-location = /path/to/zope2/install user = admin:admin http-address = 8080 eggs = ${buildout:eggs} my.package products = ${buildout:directory}/products zcml = my.package Options ------- zope2-location The path where Zope 2 is installed. If you are also using the plone.recipe.zope2install recipe, and you have that configured as a part called 'zope2' prior to the zope2instance part, you can use ${zope2:location} for this parameter. zope-conf A relative or absolute path to a zope.conf file. If this is not given, a zope.conf will be generated based on the the options below. repozo The path to the repozo.py backup script. A wrapper for this will be generated in bin/repozo, which sets up the appropriate environment for running this. Defaults to "${zope2-location}/utilities/ZODBTools/repozo.py". Set this to an empty value if you do not want this script to be generated. The following options all affect the generated zope.conf: products A list of paths where Zope 2 products are installed. The first path takes precedence in case the same product is found in more than one directory. site-zcml If you want a custom site.zcml file, put its content here. If this option is used the zcml and zcml-additional options are ignored. zcml Install ZCML slugs for the packages listed, separated by whitespace. You can specify the type of slug by appending '-' and the type of slug you want to create. The valid types are configure, overrides and meta. Some examples: my.package-overrides my.package-meta zcml-additional Extra ZCML statements that should be included in the generated site.zcml file. extra-paths A list of paths where additional python packages are installed. The paths are searched in the given order after all egg and products paths. default-zpublisher-encoding This controls what character set is used to encode unicode data that reaches ZPublisher without any other specified encoding. This defaults to 'utf-8'. debug-mode Set to 'on' to turn on debug mode in Zope. Defaults to 'off'. verbose-security Set to 'on' to turn on verbose security (and switch to the Python security implementation). Defaults to 'off' (and the C security implementation). effective-user The name of the effective user for the Zope process. Defaults to not setting an effective user. ip-address The default IP address on which Zope's various server protocol implementations will listen for requests. If this is unset, Zope will listen on all IP addresses supported by the machine. This directive can be overridden on a per-server basis in the servers section. Defaults to not setting an ip-address. port-base Offset applied to the port numbers used for ZServer configurations. For example, if the http-server port is 8080 and the port-base is 1000, the HTTP server will listen on port 9080. This makes it easy to change the complete set of ports used by a Zope server process. Zope defaults to 0. http-address Give a port for the HTTP server. Defaults to 8080. http-fast-listen Set to off to defer opening of the HTTP socket until the end of the Zope startup phase. Defaults to on. Note: This option requires Zope >= 2.11. ftp-address Give a port for the FTP server. This enables the FTP server. webdav-address Give a port for the WebDAV server. This enables the WebDAV server webdav-force-connection-close Valid options are off and on. Defaults to off client-home Sets the clienthome for the generated instance. Defaults to ${buildout:directory}/var/<name of the section>. var Used to configure the base directory for all things going into var. Defaults to ${buildout:directory}/var. event-log The filename of the event log. Defaults to var/log/${partname}.log event-log-custom A custom section for the eventlog, to be able to use another event logger than 'logfile' event-log-level Set the level of the console output for the event log. Level may be any of CRITICAL, ERROR, WARN, INFO, DEBUG, or ALL. Defaults to INFO. z2-log The filename for the Z2 access log. Defaults to var/log/${partname}-Z2.log. z2-log-level Set the log level for the access log. Level may be any of CRITICAL, ERROR, WARN, INFO, DEBUG, or ALL. Defaults to WARN. access-log-custom Like 'event-log-custom', a custom section for the access logger, to be able to use another event logger than `logfile`. file-storage The filename where the ZODB data file will be stored. Defaults to var/filestorage/Data.fs. demo-storage If 'on' it enables the demostorage. It is not compatible with blob-storage and rel-storage. blob-storage The name of the directory where the ZODB blob data will be stored. rel-storage Allows to set a RelStorage instead of a FileStorage. Contains settings separated by newlines, with these values: - type: any database type supported (postgresql, oracle, mysql) - all other keys are passed on to the database-specific RelStorage adapter. Example:: rel-storage = type oracle dsn (DESCRIPTION=(ADDRESS=(HOST=s01))(CONNECT_DATA=(SERVICE_NAME=d01))) user tarek password secret zeo-client Set to 'on' to make this instance a ZEO client. In this case, setting the zeo-address option is required, and the file-storage option has no effect. To set up a ZEO server, you can use the plone.recipe.zope2zeoserver recipe. Defaults to 'off'. shared-blob If 'zeo-client' is set to 'on' and 'blob-storage' is set to a directory that is shared between this instance and the ZEO server (as configured by the 'blob-dir' setting on zeo.conf, then setting 'shared-blob' to 'on' causes this instance not to stream the blob file through the ZEO connection, but just to send the information of the file location to the ZEO server. zeo-address Set the address of the ZEO server. Defaults to 8100. zeo-client-name Set the name of the ZEO client. Defaults to the name of the part. If a false value is provided no zeo-client-name will be set. zeo-client-cache-size Set the size of the ZEO client cache. Defaults to '30MB'. zeo-client-client Set the persistent cache name that is used to construct the cache filenames. Persistent cache files are disabled by default. zeo-storage Set the storage number of the ZEO storage. Defaults to '1'. zeo-var Used in the zeo storage snippets to configure the zeo var folder. Defaults to $INSTANCE_HOME/var. zeo-username Enable ZEO authentication and use the given username when accessing the ZEO server. It is obligatory to also specify a zeo-password. zeo-password Password to use when connecting to a ZEO server with authentication enabled. zeo-realm Authentication realm to use when authentication with a ZEO server. Defaults to 'ZEO'. zodb-cache-size Set the ZODB cache size, i.e. the number of objects which the ZODB cache will try to hold. Defaults to 5000. zodb-cache-size-bytes Set the ZODB cache sizes in bytes. Requires ZODB 3.9 or later. zserver-threads Specify the number of threads that Zope's ZServer web server will use to service requests. You shouldn't change this unless you know what you are doing. Zope's default is 4. zodb-temporary-storage If given Zope's default temporary storage definition will be replaced by the lines of this parameter. environment-vars Define arbitrary key-value pairs for use as environment variables during Zope's run cycle. Example:: environment-vars = TZ US/Eastern TMP /var/tmp DISABLE_PTS True zope-conf-additional Give additional lines to zope.conf. Make sure you indent any lines after the one with the parameter. Example:: zope-conf-additional = locale fr_FR http-realm Slipknot

plone.recipe.zope2install-3.2-5.lbn13.noarch: Options ------- To specify which Zope 2 to use, use one of the following options: url The URL to a tarball to use for the Zope 2 installation. svn The URL for an subversion checkout to use for the Zope 2 installation. location The path to a local, existing Zope 2 installation. Note: For this to work Zope must have been built with the same Python used to run buildout. fake-zope-eggs If set to true, add fake egg links to Zope 3 libraries, so that setuptools can see and use them for dependencies lookup. Enabled by default since version 3.0 of this recipe. additional-fake-eggs Specify an optional list of additional fake eggs. Only include packages which are available on the Python path. You can also specify an explicit version to fake for an egg. For example:: additional-fake-eggs = ZODB3 = 3.7.1 zope.annotation = 3.3.2 Otherwise the faked eggs will always have version 0.0. The default value includes Acquisition, ClientForm, DateTime, docutils, ExtensionClass, mechanize, Persistence, pytz, RestrictedPython, tempstorage, ZConfig, zLOG, zodbcode, ZODB3, zdaemon and Zope2. skip-fake-eggs Specify an optional list of packages, for whom no fake egg is created. This allows to pull in new versions of some of the Zope packages via normal version requirements. smart-recompile Will not recompile Zope if it finds .so or .pyd files. This means you can move your buildout around and speed up builds. If you use many buildouts with the same Zope 2 version, then you can add "zope-directory" in the "buildout" section in your ~/.buildout/default.cfg file like this:: [buildout] zope-directory = /home/me/buildout/zope For installations from a tarball that directory will be used instead of the parts directory in your buildout. Each version of Zope will get it's own directory but if it's already installed the existing one will be reused. Exported variables ------------------ The following variables are set by this recipe and can be used in other parts. location The path to the Zope installation root. Reporting bugs or asking questions ---------------------------------- We have a shared bug tracker and help desk on Launchpad: https://bugs.launchpad.net/collective.buildout/

plone.recipe.zeoserver-1.2.6-1.lbn13.noarch: ZC Buildout recipe for installing a ZEO server

plone.recipe.alltests-1.3-1.lbn13.noarch: Buildout recipe for running tests isolated at package boundaries

plone.protect-2.0.2-2.lbn13.noarch: This package contains utilities that can help to protect parts of Plone or applications build on top of the Plone framework. protect decorator ================= The most common way to use plone.protect is through the 'protect' decorator. This decorator takes a list of *checkers* as parameters: each checker will check a specific security aspect of the request

plone.principalsource-1.0b1-1.lbn13.noarch: This package provides a queriable sources (vocabularies) that return PAS users, groups or principals (both users and groups). They are registered as named vocabularies, so you can do: class IMyInterface(Interface): users = schema.Choice(title=u"Users", vocabulary="plone.principalsource.Users") groups = schema.Choice(title=u"Groups", vocabulary="plone.principalsource.Groups") principals = schema.Choice(title=u"Principals", vocabulary="plone.principalsource.Principals") The underlying source (see source.py) implements the IQuerySource interface from z3c.formwidget.query. This means that it can be used for a query-select widget, including the one in plone.formwidget.autocomplete. A note about unicode The source attempts to make it safe to do a __contains__ check, a getTerm() lookup, and searches using unicode strings. This is somewhat constrained by the underlying plugins. In particular, the standard ZODBGroups plugin is incapable of searching for groups with unicode titles or ids, and returns a list of all groups if passed a unicode string. As such, the source forces all unicode strings used to search for groups to UTF-8 (searching for users is unaffected). Also, remember that tokens should be 7-bit ASCII strings. getTermByToken() is forgiving in that it silently encodes a unicode string to utf-8, but really you should only pass unicode to this method.

plone.portlets-2.2-1.lbn13.noarch: plone.portlets provides a generic infrastructure for managing portlets. Portlets are a bit like viewlets, except they can be manipulated at runtime, using local components. This package is used by plone.app.portlets to provide Plone-specific portlets, but should be generic enough to work on other platforms. It should work in a "pure Zope 3" environment.

« Previous 20 items Next 20 items » 1 ... 2301 2302 2303 2304 2305 2306 2307 ... 2359


	Copyright © 2000-2024 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items