Configuring and Running Zope
Note
New installations should use Zope 5 instead of Zope 4. Users migrating applications from Zope 2 should upgrade to Zope 5 once their application supports Zope 4 on Python 3. The Zope developer community strives to make sure the next upgrade step to Zope 5 is and remains a quick and painless exercise.
Whichever method you used to install Zope and create a server instance (see Installing Zope), the end result is configured and operated the same way.
Note
If you have installed Zope using zc.buildout
in conjunction with
plone.recipe.zope2instance
as outlined in Installing Zope, many of
the following tasks are already done for you and some others differ
slightly. You can immediately skip down to Running Zope.
Creating a Zope instance
Attention
The following steps describe how to install a WSGI based Zope instance. If you want/have to use ZServer instead of WSGI (Python 2 only!) follow the documentation Creating a Zope instance for Zope 2.13, as it has not changed since that version.
Once you’ve installed Zope, you will need to create an “instance
home”. This is a directory that contains configuration and data for a
Zope server process. The instance home is created using the
mkwsgiinstance
script:
$ bin/mkwsgiinstance -d .
The -d . argument specifies the directory to create the instance home in.
You will be asked to provide a user name and password for an
administrator’s account during mkwsgiinstance
. To see all available
command-line options, run the script with the --help
option:
$ bin/mkwsgiinstance --help
If you followed the example and chose the current directory, you’ll
find the instances files in the subdirectories of the virtualenv
:
etc/
will hold the configuration files.var/
will hold the database files.var/log
will hold log files.
Filesystem Permissions
You need to set permissions on the directory Zope uses to store its data. This will normally be the var directory in the instance home. Zope needs to read and write data to this directory. Before running Zope you should ensure that you give adequate permissions to this directory for the user id Zope will run under.
Do not run Zope as root. Either create a user specifically for Zope or use an existing account with non-admin privileges.
Configuring Zope
Your instance’s configuration is defined in its etc/zope.conf
and etc/zope.ini
configuration files.
When starting Zope, if you see errors indicating that an address is in use, then you may have to change the ports Zope uses for HTTP. The default HTTP port used by Zope is 8080. You can change the port used by editing ./etc/zope.ini appropriately.
The section in the configuration file looks like this:
[server:main]
use = egg:waitress#main
host = 127.0.0.1
port = 8080
After making any changes to the configuration file, you need to restart any running Zope server for the affected instance before changes are in effect.
For a full description of the supported sections and directives for
zope.conf
, refer to the configuration reference section.
Running Zope
Running Zope in the foreground
To run Zope without detaching from the console, use:
$ bin/runwsgi -v etc/zope.ini
Starting server in PID 24934.
serving on http://127.0.0.1:8080
In this mode, Zope emits its log messages to the console, and does not detach from the terminal.
By default this command does not enable Zope’s debug mode, so it can be used for production.
In order to enable debug mode, you can add the additional -d
or
--debug
argument to the command:
$ bin/runwsgi -dv etc/zope.ini
Starting server in PID 55111.
serving on http://127.0.0.1:8080
The runwsgi commands takes a PasteDeploy configuration file as its argument. You can configure different WSGI capable servers, the WSGI pipeline or logging configuration in this file.
Now you are able to log in using a browser, as described in Logging In To Zope.
Running Zope as a Daemon
Zope itself has no built-in support for running as a daemon any more.
If you create your Zope instance using plone.recipe.zope2instance
you can
use its start/stop script to daemonize Zope. See the next section for how to do
that.
Alternatively, you can use projects like supervisord to achieve this or use
your operating system’s built-in process manager, like systemd
on most
Linux versions. As an example, the following systemd
service configuration
works with the runwsgi
script. It assumes your buildout is located at
/opt/zopeinstance
and the user account your Zope instance runs under is
zope
:
[Unit]
Description=Zope client zopeinstance
After=network.target
[Service]
Type=simple
User=zope
ExecStart=/opt/zopeinstance/bin/runwsgi /opt/zopeinstance/etc/zope.ini
KillMode=control-group
TimeoutStartSec=10
TimeoutStopSec=10
[Install]
WantedBy=multi-user.target
Save this configuration under /etc/systemd/system/zopeinstance.service
and
execute systemctl daemon-reload
for systemd
to read it. After that you
can use standard systemctl
commands to start, restart or stop the Zope
instance:
[root@server]# systemctl start zopeinstance
[root@server]# systemctl restart zopeinstance
[root@server]# systemctl status zopeinstance
[root@server]# systemctl stop zopeinstance
...
Debugging Zope
In order to debug the Zope application, it can be helpful to connect to its database and inspect or change it on the command line. This feature was previously available via the dedicated zopectl debug command - in the new WSGI setup this is available via the zconsole module and console script:
$ bin/zconsole debug etc/zope.conf
>>> app
<Application at >
>>> app.acl_users
<UserFolder at /acl_users>
>>> import transaction
>>> transaction.begin()
>>> app.acl_users._doAddUser('foo', 'bar', ['Manager'], [])
<User 'foo'>
>>> transaction.commit()
Running scripts
This was previously availabe using zopectl run <path_to_script> <scriparg1> …. Again in the WSGI setup the zconsole module and console script can be used:
$ bin/zconsole run etc/zope.conf <path_to_script> <scriptarg1> ...
Adding users
If you need to add a Manager to an existing Zope instance, you can do this using addzope2user as follows:
$ bin/addzope2user user password
The script expects to find the configuration file at etc/zope.conf
.
Running Zope (plone.recipe.zope2instance install)
Scipt names and invocations vary slightly in installations that use
plone.recipe.zope2instance
, but the outcome is the same as described above.
The following examples assume that the name of the buildout section was
zopeinstance
.
Running Zope in the foreground
To run Zope without detaching from the console, use:
$ bin/zopeinstance fg
...
Serving on http://127.0.0.1:8080
Running Zope as a Daemon
The zopeinstance
runner script can daemonize the Zope process:
$ bin/zopeinstance start
...
daemon process started, pid=60116
Here’s how to get status information and how to stop the Zope instance:
$ bin/zopeinstance status
program running; pid=60116
$ bin/zopeinstance stop
...
daemon process stopped
To have your instance start automatically upon reboot, you will need to
integrate with your operating system’s service startup facility. As an example,
the following systemd
service configuration works with the start/stop
script generated by plone.recipe.zope2instance
. It assumes the script name
is zopeinstance
, your buildout is located at /opt/zopeinstance
and the
user account your Zope instance runs under is zope
:
[Unit]
Description=Zope client zopeinstance
After=network.target
[Service]
Type=forking
User=zope
ExecStart=/opt/zopeinstance/bin/zopeinstance start
PIDFile=/opt/zopeinstance/var/zopeinstance/Z4.pid
ExecStop=/opt/zopeinstance/bin/zopeinstance stop
ExecReload=/opt/zopeinstance/bin/zopeinstance stop && /opt/zopeinstance/bin/zopeinstance start
KillMode=control-group
TimeoutStartSec=10
TimeoutStopSec=10
[Install]
WantedBy=multi-user.target
Save this configuration under /etc/systemd/system/zopeinstance.service
and
execute systemctl daemon-reload
for systemd
to read it. After that you
can use standard systemctl
commands to start, restart or stop the Zope
instance:
[root@server]# systemctl start zopeinstance
[root@server]# systemctl restart zopeinstance
[root@server]# systemctl status zopeinstance
[root@server]# systemctl stop zopeinstance
...
Debugging Zope
Debugging can be done at the command line:
$ bin/zopeinstance debug
Starting debugger (the name "app" is bound to the top-level Zope object)
>>> app
<Application at >
>>> app.acl_users
<OFS.userfolder.UserFolder object at ...>
>>> import transaction
>>> transaction.begin()
>>> app.acl_users._doAddUser('foo', 'bar', ['Manager'], [])
<User 'foo'>
>>> transaction.commit()
Running scripts
You can run Python scripts from the command line. The name app
is injected
into the top level namespace, it represents the root application object for
your site.
$ bin/zopeinstance run <path_to_script> <scriptarg1> ...
Adding users
If you need to add a Manager to an existing Zope instance:
$ bin/zopeinstance adduser user password
Created user: user
Logging In To Zope
Once you’ve started Zope, you can then connect to the Zope webserver by directing your browser to:
http://yourhost:8080/manage
where ‘yourhost’ is the DNS name or IP address of the machine running Zope. If you changed the HTTP port as described, use the port you configured.
You will be prompted for a user name and password. Use the user name
and password you provided in response to the prompts issued during
the Zope instance creation, or configured into your buildout configuration
for installs based on plone.recipe.zope2instance
.
Now you’re off and running! You should be looking at the Zope management screen which is divided into two frames. On the left you can navigate between Zope objects and on the right you can edit them by selecting different management functions with the tabs at the top of the frame.
To create content to be rendered at http://yourhost:8080/ create a Page
Template or DTML Document named index_html
.
Special access user accounts
The Initial User
An initial username and password is needed to “bootstrap” the creation of normal managers of your Zope site. This is accomplished through the use of the ‘inituser’ file in the directory specified as the instance home.
The first time Zope starts, it will detect that no users have been defined in the root user folder. It will search for the ‘inituser’ file and, if it exists, will add the user defined in the file to the root user folder.
Normally, ‘inituser’ is created by the makewsgiinstance
install
script.
The super user (“break glass in emergency” user)
If you find yourself locked out of your Zope instance you can create a user
by placing a file named access
in the directory specified as the instance
home. The file has one line with a colon-separated login and password, like:
superuser:mysecretpassword
Now restart Zope and use these credentials to log in. This type of user account cannot create any content, but it can add new users to the user folder or edit existing users to get you out of a bind.
Do not forget to delete the access
file and restart Zope when you are
done.
Troubleshooting
This version of Zope requires Python 2.7 or Python 3.5 and later. It will not run with any version of PyPy.
To build Python extensions you need to have Python configuration information available. If your Python comes from an RPM you may need the python-devel (or python-dev) package installed too. If you built Python from source all the configuration information should already be available.
See the Change log for important notes on this version of Zope.
Zope configuration reference
- zodb.storage*
- <blobstorage> (ZODB.config.BlobStorage)
- blob-dir (string)
Path name to the blob storage directory.
- zodb.storage*
- <demostorage> (ZODB.config.DemoStorage)
- name (string)
The storage name, used by the
getName()
andsortKey()
methods.- zodb.storage*
- <filestorage> (ZODB.config.FileStorage)
- path (existing-dirpath)
Path name to the main storage file. The names for supplemental files, including index and lock files, will be computed from this.
- blob-dir (existing-dirpath)
If supplied, the file storage will provide blob support and this is the name of a directory to hold blob data. The directory will be created if it doesn’t exist. If no value (or an empty value) is provided, then no blob support will be provided. (You can still use a BlobStorage to provide blob support.)
- create (boolean)
Flag that indicates whether the storage should be truncated if it already exists.
- read-only (boolean)
If true, only reads may be executed against the storage. Note that the “pack” operation is not considered a write operation and is still allowed on a read-only filestorage.
- quota (byte-size)
Maximum allowed size of the storage file. Operations which would cause the size of the storage to exceed the quota will result in a ZODB.FileStorage.FileStorageQuotaError being raised.
- packer (string)
The dotted name (dotted module name and object name) of a packer object. This is used to provide an alternative pack implementation.
- pack-gc (boolean) (default: true)
If false, then no garbage collection will be performed when packing. This can make packing go much faster and can avoid problems when objects are referenced only from other databases.
- pack-keep-old (boolean) (default: true)
If true, a copy of the database before packing is kept in a “.old” file.
- <fullstorage> (ZODB.config.BDBFullStorage)
- envdir (string)
- interval (time-interval) (default: 2m)
- kbyte (integer) (default: 0)
- min (integer) (default: 0)
- logdir (string)
- cachesize (byte-size) (default: 128MB)
- frequency (time-interval) (default: 0)
- packtime (time-interval) (default: 4h)
- gcpack (integer) (default: 0)
- read-only (boolean) (default: off)
- <mappingstorage> (ZODB.config.MappingStorage)
- name (string) (default: Mapping Storage)
The storage name, used by the
getName()
andsortKey()
methods.
- <minimalstorage> (ZODB.config.BDBMinimalStorage)
- envdir (string)
- interval (time-interval) (default: 2m)
- kbyte (integer) (default: 0)
- min (integer) (default: 0)
- logdir (string)
- cachesize (byte-size) (default: 128MB)
- frequency (time-interval) (default: 0)
- packtime (time-interval) (default: 4h)
- gcpack (integer) (default: 0)
- read-only (boolean) (default: off)
- <temporarystorage> (tempstorage.config.TemporaryStorage)
A nonundoing storage which keeps data in RAM and which does not need to be packed unless cyclic references are kept.
- name (string) (default: Temporary Storage)
- <zeoclient> (ZODB.config.ZEOClient)
- server (*) (socket-connection-address)
- blob-dir (string)
Path name to the blob cache directory.
- shared-blob-dir (boolean) (default: no)
Tells whether the cache is a shared writable directory and that the ZEO protocol should not transfer the file but only the filename when committing.
- blob-cache-size (byte-size)
Maximum size of the ZEO blob cache, in bytes. If not set, then the cache size isn’t checked and the blob directory will grow without bound.
This option is ignored if shared_blob_dir is true.
- blob-cache-size-check (integer)
ZEO check size as percent of blob_cache_size. The ZEO cache size will be checked when this many bytes have been loaded into the cache. Defaults to 10% of the blob cache size. This option is ignored if shared_blob_dir is true.
- storage (string) (default: 1)
The name of the storage that the client wants to use. If the ZEO server serves more than one storage, the client selects the storage it wants to use by name. The default name is ‘1’, which is also the default name for the ZEO server.
- cache-size (byte-size) (default: 20MB)
The maximum size of the client cache, in bytes, KB or MB.
- name (string)
The storage name. If unspecified, the address of the server will be used as the name.
- client (string)
Enables persistent cache files. The string passed here is used to construct the cache filenames. If it is not specified, the client creates a temporary cache that will only be used by the current object.
- var (string)
The directory where persistent cache files are stored. By default cache files, if they are persistent, are stored in the current directory.
- min-disconnect-poll (integer) (default: 5)
The minimum delay in seconds between attempts to connect to the server, in seconds. Defaults to 5 seconds.
- max-disconnect-poll (integer) (default: 300)
The maximum delay in seconds between attempts to connect to the server, in seconds. Defaults to 300 seconds.
- wait (boolean) (default: on)
A boolean indicating whether the constructor should wait for the client to connect to the server and verify the cache before returning. The default is true.
- read-only (boolean) (default: off)
A flag indicating whether this should be a read-only storage, defaulting to false (i.e. writing is allowed by default).
- read-only-fallback (boolean) (default: off)
A flag indicating whether a read-only remote storage should be acceptable as a fall-back when no writable storages are available. Defaults to false. At most one of read_only and read_only_fallback should be true.
- username (string)
The authentication user name of the server.
- password (string)
The authentication password of the server.
- realm (string)
The authentication realm of the server. Some authentication schemes use a realm to identify the logic set of user names that are accepted by this server.
- drop-cache-rather-verify (boolean) (default: off)
A flag indicating whether the client cache should be dropped instead of an expensive verification.
- client-label (string)
A label for the client in server logs
- zodb.storage*
- zodb.storage*
- zodb.database+
Zope ZODB databases must have a name, and they are required to be referenced via the “zodb_db” database type because it is the only kind of database definition that implements the required mount-point argument. There is another database sectiontype named “zodb”, but it cannot be used in the context of a proper Zope configuration (due to lack of a mount-point).
- <zodb> (ZODB.config.ZODBDatabase)
- zodb.storage*
- cache-size (integer) (default: 5000)
Target size, in number of objects, of each connection’s object cache.
- cache-size-bytes (byte-size) (default: 0)
Target size, in total estimated size for objects, of each connection’s object cache. “0” means no limit.
- large-record-size (byte-size) (default: 16MB)
When object records are saved that are larger than this, a warning is issued, suggesting that blobs should be used instead.
- pool-size (integer) (default: 7)
The expected maximum number of simultaneously open connections. There is no hard limit (as many connections as are requested will be opened, until system resources are exhausted). Exceeding pool-size connections causes a warning message to be logged, and exceeding twice pool-size connections causes a critical message to be logged.
- pool-timeout (time-interval)
The minimum interval that an unused (non-historical) connection should be kept.
- historical-pool-size (integer) (default: 3)
The expected maximum total number of historical connections simultaneously open.
- historical-cache-size (integer) (default: 1000)
Target size, in number of objects, of each historical connection’s object cache.
- historical-cache-size-bytes (byte-size) (default: 0)
Target size, in total estimated size of objects, of each historical connection’s object cache.
- historical-timeout (time-interval) (default: 5m)
The minimum interval that an unused historical connection should be kept.
- database-name (string)
When multi-databases are in use, this is the name given to this database in the collection. The name must be unique across all databases in the collection. The collection must also be given a mapping from its databases’ names to their databases, but that cannot be specified in a ZODB config file. Applications using multi-databases typical supply a way to configure the mapping in their own config files, using the “databases” parameter of a DB constructor.
- allow-implicit-cross-references (boolean)
If set to false, implicit cross references (the only kind currently possible) are disallowed.
- <zodb_db> (Zope2.Startup.datatypes.ZopeDatabase)
We need to specialize the database configuration section for Zope only by including a (required) mount-point argument, which is a string. A Zope ZODB database can have multiple mount points, so this is a multikey.
- zodb.storage*
- cache-size (integer) (default: 5000)
Target size, in number of objects, of each connection’s object cache.
- cache-size-bytes (byte-size) (default: 0)
Target size, in total estimated size for objects, of each connection’s object cache. “0” means no limit.
- large-record-size (byte-size) (default: 16MB)
When object records are saved that are larger than this, a warning is issued, suggesting that blobs should be used instead.
- pool-size (integer) (default: 7)
The expected maximum number of simultaneously open connections. There is no hard limit (as many connections as are requested will be opened, until system resources are exhausted). Exceeding pool-size connections causes a warning message to be logged, and exceeding twice pool-size connections causes a critical message to be logged.
- pool-timeout (time-interval)
The minimum interval that an unused (non-historical) connection should be kept.
- historical-pool-size (integer) (default: 3)
The expected maximum total number of historical connections simultaneously open.
- historical-cache-size (integer) (default: 1000)
Target size, in number of objects, of each historical connection’s object cache.
- historical-cache-size-bytes (byte-size) (default: 0)
Target size, in total estimated size of objects, of each historical connection’s object cache.
- historical-timeout (time-interval) (default: 5m)
The minimum interval that an unused historical connection should be kept.
- database-name (string)
When multi-databases are in use, this is the name given to this database in the collection. The name must be unique across all databases in the collection. The collection must also be given a mapping from its databases’ names to their databases, but that cannot be specified in a ZODB config file. Applications using multi-databases typical supply a way to configure the mapping in their own config files, using the “databases” parameter of a DB constructor.
- allow-implicit-cross-references (boolean)
If set to false, implicit cross references (the only kind currently possible) are disallowed.
- mount-point (*) (Zope2.Startup.datatypes.mount_point)
The mount point is a slash-separated path to a ‘Products.ZODBMountPoint.Mount.MountPoint’ instance in Zope. If such an instance exists, it can mount an object (the mounted object) into Zope. By default, the object will be mounted at the same path in Zope (i.e. ‘/foo/bar’ in the database will be mounted at ‘/foo/bar’ in Zope).
The object can be mounted at a different point using the ‘virtual_path:real_path’ syntax (e.g. ‘mount-point /foo/bar:/bar’ will mount the object at ‘/bar’ in the database to ‘/foo/bar’ in Zope). The name of the mount point (‘bar’) must be the same as the mounted object.
It is also possible to specify the root that should be used in the mounted database by using the syntax ‘virtual_path:~real_root:real_path’. The root defaults to ‘Application’ and should not normally be changed.
- connection-class (Zope2.Startup.datatypes.importable_name)
Change the connection class a database uses on a per-database basis to support different connection policies. Use a Python dotted-path name to specify the connection class.
- class-factory (Zope2.Startup.datatypes.importable_name) (default: Zope2.Startup.datatypes.simpleClassFactory)
Change the class factory function a database uses on a per-database basis to support different class factory policy. Use a Python dotted-path name to specify the class factory function.
- container-class (string)
Change the container class a (mounted) database uses on a per-database basis to support a different container than a plain Folder. Use a Python dotted-path name to specify the container class.
- zope.product.base+
Product-specific configuration stanzas.
Products may use the <product-config> section type, or may supply a component.xml which defines section types with their own schemas.
All sections for this multisection will be collected into the ‘product_config’ attribute of the configuration object.
Base type for product-specific configuration sections.
Specific products should implement configuration sections by defining section types that implement this abstract type and using their own schema component to define meaningful settings.
- product-config (null)
Product-specific configuration, expressed as arbitrary name-value pairs.
- + (string)
- <environment> (Zope2.Startup.datatypes.environment)
A section which allows you to define simple key-value pairs which will be used as environment variable settings during startup.
- + (string)
Use any key/value pair, e.g. ‘MY_PRODUCT_ENVVAR foo_bar’
- zodb.database
- zodb.storage
- zope.product.base
Base type for product-specific configuration sections.
Specific products should implement configuration sections by defining section types that implement this abstract type and using their own schema component to define meaningful settings.
- <environment *> (Zope2.Startup.datatypes.environment)
- + (string)
Use any key/value pair, e.g. ‘MY_PRODUCT_ENVVAR foo_bar’
- instancehome (existing-directory)
The top-level directory which contains the “instance” data for the application server. It may also contain “etc”, “bin”, “log”, and “var” directories depending on how you’ve configured your Zope instance.
- clienthome (existing-directory) (metadefault: $instancehome/var)
The directory used to store the default filestorage file used to back the ZODB database, as well as other files used by the Zope applications server during runtime.
- debug-mode (boolean) (default: off) (metadefault: off)
A switch which controls several aspects of Zope operation useful for developing under Zope. When debug mode is on:
Errors in product initialization will cause startup to fail (instead of writing error messages to the event log file).
Filesystem-based scripts such as skins, PageTemplateFiles, and DTMLFiles can be edited while the server is running and the server will detect these changes in real time. When this switch is off, you must restart the server to see the changes.
Setting this to ‘off’ when Zope is in a production environment is encouraged, as it speeds execution (sometimes dramatically).
- debug-exceptions (boolean) (default: off) (metadefault: off)
This switch controls how exceptions are handled. If it is set to “off” (the default), Zope’s own exception handling is active. Exception views or a standard_error_message are used to handle them.
If set to “on”, exceptions are not handled by Zope and can propagate into the WSGI pipeline, where they may be handled by debugging middleware.
This setting should always be “off” in production. It is useful for developers and while debugging site issues.
- locale (locale) (metadefault: unset)
Locale name to be used. See your operating system documentation for locale information specific to your system. If the requested locale is not supported by your system, an error will be raised and Zope will not start.
- datetime-format (Zope2.Startup.datatypes.datetime_format) (default: us) (metadefault: us)
Set this variable either to “us” or “international” to force the DateTime module to parse date strings either with month-before-days-before-year (“us”) or days-before-month-before-year (“international”). The default behaviour of DateTime (when this setting is left unset) is to parse dates as US dates.
- python-check-interval (integer) (default: 1000)
Value passed to Python’s sys.setcheckinterval() function. The higher this is, the less frequently the Python interpreter checks for keyboard interrupts. Setting this to higher values also reduces the frequency of potential thread switches, which can improve the performance of a busy server.
- http-realm (string) (default: Zope) (metadefault: Zope)
The HTTP “Realm” header value sent by this Zope instance. This value often shows up in basic authentication dialogs.
- automatically-quote-dtml-request-data (boolean) (default: on) (metadefault: on)
Set this directive to ‘off’ in order to disable the autoquoting of implicitly retrieved REQUEST data by DTML code which contains a ‘<’ when used in <dtml-var> construction. When this directive is ‘on’, all data implicitly retrieved from the REQUEST in DTML (as opposed to addressing REQUEST.somevarname directly) that contains a ‘<’ will be HTML-quoted when interpolated via a <dtml-var> or &dtml- construct. This mitigates the possibility that DTML programmers will leave their sites open to a “client-side trojan” attack.
- zmi-bookmarkable-urls (boolean) (default: on) (metadefault: on)
Set this directive to ‘on’ to cause Zope to show the ZMI right hand frame’s URL in the browser navigation bar as opposed to the static ‘/manage’. The default is ‘on’. To restore the behavior of Zope 2 where the URL was always static unless you opened the right-hand frame in its own browser window, set this to off.
- pid-filename (existing-dirpath) (metadefault: $clienthome/Z4.pid)
The full path to which the Zope process will write its OS process id at startup.
- trusted-proxy (*) (ipaddr-or-hostname) (metadefault: unset)
Define one or more ‘trusted-proxies’ keys, each of which is a hostname or an IP address. The set of definitions comprises a list of front-end proxies that are trusted to supply an accurate X_FORWARDED_FOR header to Zope (security-related).
- max-conflict-retries (integer) (default: 3)
The maximum number of retries on a conflict error
- security-policy-implementation (Zope2.Startup.datatypes.security_policy_implementation) (default: C) (metadefault: C)
The default Zope “security policy” implementation is written in C. Set this key to “PYTHON” to use the Python implementation (useful for debugging purposes); set it to “C” to use the C implementation.
- skip-authentication-checking (boolean) (default: off) (metadefault: off)
Set this directive to ‘on’ to cause Zope to prevent Zope from attempting to authenticate users during normal operation. Potentially dangerous from a security perspective. Only works if security-policy-implementation is set to ‘C’.
- skip-ownership-checking (boolean) (default: off) (metadefault: off)
Set this directive to ‘on’ to cause Zope to ignore ownership checking when attempting to execute “through the web” code. By default, this directive is off in order to prevent ‘trojan horse’ security problems whereby a user with less privilege can cause a user with more privilege to execute code which the less privileged user has written.
- verbose-security (boolean) (default: off) (metadefault: off)
Set this directive to ‘on’ to enable verbose security exceptions. This can help you track down the reason for Unauthorized exceptions, but it is not suitable for public sites because it may reveal unnecessary information about the structure of your site. Only works if security-policy-implementation is set to ‘PYTHON’.
- default-zpublisher-encoding (Zope2.Startup.datatypes.default_zpublisher_encoding) (default: utf-8)
This key controls what character set is used to encode unicode data that reaches ZPublisher without any other specified encoding.
- webdav-source-port (integer) (default: 0)
This value designates a network port number as WebDAV source port.
WebDAV requires special handling for GET requests. A WebDAV client expects to receive the un-rendered source in the returned response body, not the rendered result a web browser would get.
If this value is set to a positive integer, any GET request coming into Zope via the designated port will be marked up to signal that this is a WebDAV request. This request markup resembles what ZServer did for requests coming though its designated WebDAV source server port, so it is backwards-compatible for existing code that offers WebDAV handling under ZServer.
Please note that Zope itself has no server capabilities and cannot open network ports. You need to configure your WSGI server to listen on the designated port.
- enable-ms-public-header (boolean) (default: off) (metadefault: off)
Set this directive to ‘on’ to enable sending the “Public” header in response to an WebDAV OPTIONS request - but only those coming from Microsoft WebDAV clients.
Though recent WebDAV drafts mention this header, the original WebDAV RFC did not mention it as part of the standard. Very few web servers out there include this header in their replies, most notably IIS and Netscape Enterprise 3.6.
Documentation about this header is sparse. Some versions of Microsoft Web Folders after 2005 apparently require its presence, but most documentation links have expired.