collective.denyroles 1.0.0b2

Features

• A patch for the PAS _authorizeUser method that checks the roles of the user, and gives no authorization when some roles are found.

• Configuration via environment variables or request headers to see if the check should be done.

Use case

You have a Plone Site on two domains:

• edit.example.local is for editing. Users with the Editor or Manager role login here to edit and manage the site. This is a local domain that can only be reached within your local network or a VPN.

• www.example.org is for anonymous users and maybe also for standard Members without extra roles. This domain is protected by a special firewall to prevent common web attacks like dubious form submissions, request flooding, spammers, cross site scripting attacks, etcetera.

Problems:

• Editors sometimes login to the public domain, and get errors during editing because the firewall is too protective.

• The system administrator complains that he has setup a special domain for editing and managing, so that no changes can come in from the public site, and yet unexpectedly the editors can login and make changes via the public site anyway.

This package gives you options to prevent users with some global roles from accessing the (public) site. To be more precise: they will be treated as anonymous. When they try to login, the login process will fail.

Installation

Install collective.denyroles by adding it to your buildout:

[buildout]

...

eggs =
    collective.denyroles

and then running bin/buildout. It is immediately active, without needing activation within the Plone Site.

You may need some more configuration in your buildout config. See the next section.

Configuration

The roles that are denied access, can be seen in src/collective/denyroles/config.py. We might make this configurable at some point. Currently they are:

• Manager

• Site Administrator

• Editor

• Reviewer

• Contributor

There are two ways to configure whether the roles should be checked or not: via environment variables or via request headers.

export DENY_ROLES=1

[instance]
recipe = plone.recipe.zope2instance
environment-vars =
    DENY_ROLES 1

X_DO_CHECK_ROLES
X_DONT_CHECK_ROLES

Suggested buildout usage

This is a suggestion on how to properly add this in a buildout. Note that this focuses on configuring collective.denyroles, and ignores lots of other useful settings:

[zeoclient]
# Configuration for public zeoclient.
recipe = plone.recipe.zope2instance
http-address = 8080
zeo-client = on
eggs =
    Plone
    collective.denyroles
# Environment variables shared by all zeoclients:
base-environment-vars =
    zope_i18n_compile_mo_files true
environment-vars =
    ${:base-environment-vars}
# In the public zeoclient, we deny access to editors/managers:
    DENY_ROLES 1

[zeoclient-cms]
# Second Plone zeoclient, only used for CMS, so for editors.
# The next weird line means: inherit all settings from the [zeoclient] section:
<= zeoclient
# Use a different port:
http-address = 8090
environment-vars =
    ${:base-environment-vars}
# In the CMS zeoclient, we do not want to deny access to editors/managers:
    DENY_ROLES 0

[instance]
# Standalone Plone instance without ZEO setup, for local development.
<= zeoclient
zeo-client = off
environment-vars =
    ${:base-environment-vars}
# With single instance, we do not want to deny access to editors/managers:
    DENY_ROLES 0

Support

If you are having issues, please let us know. Contact Maurits van Rees at Zest Software, m.van.rees@zestsoftware.nl. Or open an issue in GitHub.

License

The project is licensed under the GPLv2.

1.0.0b2 (2019-09-17)

• Fixed PyPI description. [maurits]

1.0.0b1 (2019-09-17)

• Initial release. [maurits]