Search results

collective.zopeedit-1.0.0-2.lbn19.noarch

ZopeEdit : External Editor Client

dataflake.cache-1.4-1.lbn19.noarch

This package provides a set of simple cache implementations for use in Python code. Its roots are in the internally-used SimpleCache module from Products.LDAPUserFolder.

dataflake.ldapconnection-1.5-1.lbn19.noarch

This package provides an abstraction layer on top of python-ldap. It offers a connection object with simplified methods for inserting, modifying, searching and deleting records in the LDAP directory tree. Failover/redundancy can be achieved by supplying connection data for more than one LDAP server.

dm.profile-1.0-4.lbn19.noarch

"profile.Profile" improvement I started the implementation of this module in order to improve the profiler's calibration using statistical methods. Unfortunately, variance proved to be far too high and my calibration trials did not converge even for large sample sets. I had to abandon this approach. The code is still there (in case anyone would like to look what I have tried) but I do not use it. "pstats.Stats" improvement Beside the profiler's not so good calibration, I was not satisfied with "pstats" format especially for the caller and callee analysis and with its insistence to write to "stdout". Therefore, I derived a new class Stats from pstats.Stats and added new methods showStats, showCallers and showCallees which correspond to print_stats, print_callers and print_callees. They write to a file set with setOutputFile (default sys.stdout) and use a different output format. For showCallers and showCallees it is much more readable than the format used by print_callers and print_callees. I am not sure that this is also the case for the format used for showStats versus print_stats. When you are using "Stats.print_callers" or "Stats.print_callees" and find their output unreadable, then a switch to "dm.profile.Stats" may be profitable for you. The method showHeader outputs header information (with involved files, top level functions, number of calls and profiled time).

dm.reuse-1.1-4.lbn19.noarch

Utilities to reuse (slightly modified) oybjects in new contexts. Currently, there is a single utility: rebindFunction. It allows to reuse the code of a function while changing name, globals, default arguments, properties and/or names used.

dm.saml2-3.1.3-1.lbn19.noarch

This package provides support for SAML2 based on pyxb. pyxb (http://pypi.python.org/pypi/PyXB) generates a Python class collection for an XML schema and provides means to convert between associated Python instances and xml documents. It is used to generate and parse SAML2 messages. The package adds support for digital signatures and SAML2 bindings and metadata management.

dm.xmlsec.binding-1.3.2-2.lbn19.x86_64

This package contains a Cython (http://cython.org/) based bindung to Aleksey Sanin's XML security library ("http://www.aleksey.com/xmlsec") to be used together with lxml (http://lxml.de), the most popular Python binding to the Gnome XML library libxml2 (http://xmlsoft.org).

dm.zope.saml2-3.1b2-3.lbn19.noarch

This package supports SAML2 based SSO (Single Sign-On) for Zope2/Plone installations. While it currently supports only a small subset of the SAML2 standard (simple identity provider, simple service provider integration and attribute support), its current functionality is comparable to Plone's OpenId support. Architecture In the SAML2 architecture, a set of distributed authorities (aka entities) cooperate to provide an overall service. Each authority can take over one or more roles. Roles are for example "identity provider" (can identify users), "service provider" (provides some service) and "attribute provider" (can provide information about users). Authorities and their roles are described by metadata. The metadata is exchanged between authorities to allow them to cooperate. SAML2 messages are exchanged to implement the SSO (and other) functionality. The package currently provides an SAML2 authority, a simple identity provider, a simple service provider integration and a simple attribute provider. All functions are implemented via objects created via the Zope management interface (ZMI). Authority The SAML authority object represents the local SAML authority and manages the metadata about the foreign authorities cooperating with it. Its metadata method (callable via url) returns the metadata describing the local authority. Foreign authorities are managed as so called Entity objects; their metadata are automatically updated (based on validity attributes in the metadata), manual update is supported for special cases. The objects implementing SAML2 roles access "their" authority as a (Zope toolkit) "utility". To make this possible, an SAML authority can only be created below a (Zope toolkit) site (see the package five.localsitemanager to learn about sites and how to create one). (CMF or Plone) portals are sites (in this sense) automatically. Thus, in a simple setup, you can create an authority object in a portal (without special actions concerning sites). There can be at most one SAML authority in a given site. Nested sites, however, may have their own authority or use that of a parent site. Identity Provider In general, an identity provider has the task to identify users and to provide assertions about user identities to service providers. The provided simple identity provider delegates the first task (identifying users) to a host CMF or Plone portal. Thereby, it uses the standard portal functionality for login and authentication; it does not make any assumption about the way the portal manages its users (and their attributes) and the details of the authentication process. Thus, almost any portal can be made into an SAML2 identity provider by just creating an "Saml simple identity provider" in the portal. On creation, the identity provider registers automatically as "identity provider" role with an SAML authority utility. Creation fails, if this utility either cannot be located or already knows about an identity provider. There is a variant identity provider which integrates elemantary attribute provider functionality (see section "Attribute Support"). Service Provider In general, an SAML2 service provider provides some kind of (web) service to users and uses SAML2 to get information about the identities, attributes or access rights for some of its users. The service provided itself has nothing to do with SAML2; it can be almost anything (using web technologies). Only a small part has to do with SAML2: getting information about users identified and managed externally by other SAML2 authorities. The simple service provider functionality in this package allows either a single portal or a family of portals sharing a common service provider description to get authentication information from an SAML2 identity provider. It interfaces with the portal[s] via the miniframework "pluggable authentication service", used by (e.g.) Plone portals. In the simple case, the (real) service is implemented by a single portal which should get authentication information from one or more SAML2 identity providers. This use case is supported by the creation of an "Saml integrated simple spsso plugin" in the portal's acl_users and the activation of its interfaces. If the SAML2 based authentication replaces the local one, plugins responsible for local authentication may need to be removed or their interfaces deactivated. Some integration work is necessary, when local authentication should coexist with SAML2 based authentication (essentially, the login form (for local authentication) must be combined with the identity provider selection (for external authentication)). In the more complex case, the (real) service is not provided by a single portal but by a whole family of portals (usually providing the same service or slightly customized variants of the same service to different user groups) sharing a common service description with respect to SAML2. In this case, there is a shared Saml service provider and each portal has an Saml simple spsso plugin (external spsso) which work with the shared service provider. In this case, service provider and plugin communicate via cookies. Therefore, they must get the same cookies. In fact, the simple case is a variant of the complex one where service provider and plugin are implemented by the same object. When a service provider object is created (either standalone or integrated with the plugin), it registers as "service provider" role with an SAML authority utility. Creation fails, if this utility either cannot be located or already knows about a service provider. The servide provider integration can exhibit user attributes from the SAML2 assertions as user properties in the portal (user properties are a standard feature of Plone portals -- to provide addtional information such as name, email address, ... for a user). Attribute Support General SAML2 Attribute Support This section sketches the general principles of SAML2 attribute support. The next section outlines the support provided by this package. The SAML2 assertions about a user can include almost arbitrary attributes to provide additional information (beyond the identity). Attributes can for example be used to inform a cooperating SAML authority about the name, the email address, group membership or special priviledges of a user. SAML2 attributes are identified by a name format and a (formal, often unwieldy) name. Optionally, they can have a so called "FriendlyName" which should be human readable. SAML2 allows a service provider to define zero or more "AttributeConsumingService"s. Each "AttributeConsumingService" is identified by an index (an integer) and contains a sequence of descriptions for "RequestedAttribute"s. When the service provider requests authentication for a user, it can specify for which of its "AttributeConsumingService"s it wants attribute information. An SAML2 attribute provider is able to provide attributes for users. Metadata tells which attributes can be provided. Attribute Support in this Package This package describes attributes by objects, managed in "Folder"s and identified by (locally unique) ids. The ids are used as "FriendlyName" in the SAML metadata and as user property name. The attribute's SAML2 name format and (formal) name are specified by attributes of the attribute (describing) object. Attribute values can be instances of an XML-Schema elementary type or lists/sequences thereof (however, Plone may not understand some of those types). The service provider object is implemented as a "Folder" of "AttributeConsumingService"s, each "AttributConsumingService" as a "Folder" of "RequestedAttribute"s. Thus, a service provider can define various sets of interesting attributes. However, the standard authentication request requests only the default set. While there is an authentication method which supports the specification of the wanted "AttributeConsumingService", it is likely that this in not yet handled correctly in this version. The service provider plugin exposes the SAML2 attributes for a user as standard (for Plone) user properties; the id of the attribute description is used as user property name. The current package version does not have a standalone attribute provider. However, there is an identity provider variant which has some integrated attribute provider functionality. It provides attribute information only as part of authentication requests. It is implemented as a "Folder" of "Attribute"s which describe the supported attributes and how their value can be computed. By default, the id of the attribute description is interpreted as user property name and its value (for the current user) used as value for the attribute. Alternatively, the attribute definition can specify an "Evaluator" -- the name of a method or view called with parameters member, attr and eid to determine the attribute value. member is the current portal member, attr the attribute description and eid the entity identifier who should get the information.

dm.zope.schema-2.1-2.lbn19.noarch

This package contains extensions for zope.schema. Modules verify A companion to zope.interface.verify for the schema part of interfaces. It contains the function verify_schema(iface, obj, context=None, check_declaration=True) which verifies that obj satisfies the schema part of interface iface. Schema fields need to get bound to a context before they can be validated. context specifies this context and defaults to obj. check_declaration checks that obj declares to privide iface. schema The main content is the mixin class SchemaConfigured. It supports configuration according the schema part of the interfaces implemented by the SchemaConfigured derived class. If you want to control from which interfaces the schema is derived, you can use the class attribute SC_SCHEMAS: its value should be None (derive schema automatically from the implemented interfaces), a single interface or a tuple of interfaces. Taking explicit control over the interfaces used to determine the schema is especially important for Zope 2 schema configured content classes (as their base class OFS.SimpleItem.SimpleItem implements a huge number of interfaces whose fields you likely do not want in your schema). The mixin class SchemaConfiguredEvolution provides support for schema evolution for (ZODB) persistent objects. Its __setstate__ adds missing attributes to the object such that you can add new fields to your schema and still find all corresponding attributes on the respective objects even when those have been created before the extension. Note: in order for SchemaConfiguredEvolution to be effective, it must come early in the method resolution order (mro) (before persistent.Persistent). That's why is is a separate class and its feature not included in SchemaConfigured itself (there may be good reasons to have SchemaConfigured late in the mro). As an alternative to the use of SchemaConfiguredEvolution, you can use default values defined on class level for new fields. Occasionally, functions schemaitems and schemadict might be usefull. They extract the schema part of an interface or interface specification as a list of id, field pairs or a dictionary, respectively. The field Object is a replacement for zope.schema.Object. The latter lacks field information in validation errors (https://bugs.launchpad.net/zope.schema/+bug/620324) which makes identification of the affected fields unnecessarily difficult. Occasionally, one wants to suppress the check that a validated object explicitly declares to provide the interface. Object has the additional property check_declaration to control this (defaults to True). propertymanager This module implements a schema based OFS.PropertyManager.PropertyManager subclass. The _properties attribute describing the properties is not maintained on the class or its instances but derived from the provided (respectively implemented) schemas. For the moment, properties cannot be extended on an instance based level (other than by providing another schema). zope.schema uses unicode to represent text. PropertyManager can in principle support unicode properties. However, due to a bug/weakness, the property management page handles them correctly only, when management_page_charset is not defined or has value UTF-8 (note the upper case spelling!). We use unicode properties by default unless management_page_charset.upper() yields a value different from UTF-8. We also provide a mixin class WorkaroundSpelling_management_page_charset to work around Zope's stupid insistence on upper case spelling for management_page_charset. For the moment, the following field types are supported: Text, TextLine, Bytes, BytesLine`, Bool, Int, Float and List with a value type of TextLine or BytesLine. Other types will raise NotImplementedError. The module has been implemented to leverage dm.zope.generate. An alternative would have been the implementation of the generation facilities based on "zope.formlib" and the use of so called add forms. Depending on experience, I may switch to this alternative. form The module defines default edit (SchemaConfiguredEditForm) and display (SchemaConfiguredDisplayForm) forms for dm.zope.schema.schema.SchemaConfigured. It depends on zope.formlib. widget Provides display and edit widgets for Timedelta fields, a decent display widget for Password fields (the default displays passwords in cleartext) and an input widget for Password that does not force you to provide the password value whenever you edit the form. It depends on zope.app.form in older Zope versions and on zope.formlib in newer ones. z2 This subpackage combines schema related and Zope 2 functionality. In newer Zope versions, it depends on five.formlib. form The module defines default edit (SchemaConfiguredEditForm) and display (SchemaConfiguredDisplayForm) forms for dm.zope.schema.schema.SchemaConfigured for use in Zope 2. It depends on zope.formlib. constructor This module contains an add form class SchemaConfiguredAddForm and a factory add_form_factory for the generation of an add form (called "constructor" by Zope 2) for dm.zope.schema.schema.SchemaConfigured based classes. The generated add form is usually used as part of the constructors parameter to registerClass. add_form_factory has the parameters: name default description class_ the class to generate the form for title Create instance of class_ the title shown in the form description class_.__doc__ the documentation shown in the form form_class SchemaConfiguredAddForm form class to be used add_form_factory generates a zope.formlib form with fields defined by the implemented schemas of dm.zope.schema.schema.SchemaConfigured class class_. This module is similar to dm.zope.generate.constructor. However, it works for SchemaConfigured based classes while the latter supports PropertyManager based classes. template Provides the view page template form_template able to view and edit Zope 2 schema configured content objects within the standard ZMI interface.

eea.alchemy-6.3-1.lbn19.noarch

Auto-discover geographical coverage, temporal coverage, related items and keywords from documents common metadata (title, description, body, etc), auto highlight keywords within a page content based on selected tags and auto-update related items based on internal links found within object's metadata.