Package: collective.droproles
collective.droprolesThis is a monkey patch for PAS (PluggableAuthService).
It drops roles like Manager or Editor on Plone Sites.
An Editor can still login, but only has the Member and Authenticated roles.It differs fromcollective.denyroleswhich completely denies access to someone with one of these roles: they cannot login.
This login failure may be confusing.
I want to move the sites where I used this, over to the newercollective.droproles.FeaturesA patch for methodsgetRoles,getRolesInContext, andallowedon various user classes,
returning the original list, but with the following roles removed:
Manager, Site Administrator, Editor, Reviewer, Contributor.
This is temporary: no database changes are made.Configuration via environment variableDROP_ROLES.
By default we do not drop roles, but withDROP_ROLES=1, we do drop them.Use caseYou 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 the option to treat all users as having at most the Member or Authenticated roles.
A Manager can login, but cannot go to the Plone overview controlpanel.User classesThe following classes are patched:AccessControl.users.BasicUser
AccessControl.users.SimpleUser
Products.PlonePAS.plugins.ufactory.PloneUser
Products.PluggableAuthService.PropertiedUser.PropertiedUserThis covers standard Plone.I havenottested with users coming from other sources, like LDAP.
It might work out of the box though.
If it does not work, and your LDAP users have a special class, try callingpatch_class(your_ldap_class).Dropped rolesThe following roles are dropped:Manager
Site Administrator
Editor
Reviewer
ContributorIf you have other roles that you want to drop, you may need to add it to the set ofUSER_CLASSESvia a monkey patch.See also theDropping all rolessection.InstallationInstall collective.droproles by adding it to your buildout:[buildout]

...

eggs =
    collective.droproles

[instance]
recipe = plone.recipe.zope2instance
environment-vars =
    DROP_ROLES 1and then runningbin/buildout.Without the environment variable, it does nothing.ConfigurationYou can set an environment variable to drop the roles:export DROP_ROLES=1Set this to 1 (or another positive integer) for yes, and 0 for no.
Any other values will be ignored.Note that the OS environment can be different when you manually start your Plone instance or start it in a cronjob.
So it is better to set this in your Plonebuildout.cfg:[instance]
recipe = plone.recipe.zope2instance
environment-vars =
    DROP_ROLES 1Run the buildout and it will be set in the Plone config,
in this case inparts/instance/etc/zope.conf.If you have a ZEO setup with two zeoclients, where one zeoclient gets all traffic from editors, and another gets the anonymous visitors, you can do this:zeoclient for editors:DROP_ROLES 0zeoclient for anonymous:DROP_ROLES 1Now editors can edit normally in their edit environment.
And when they accidentally login on the anonymous environment, they will be treated as simple Members without extra roles.Technically,DROP_ROLES 0does nothing, because it is the default.
But it may be good to be specific.Dropping all rolesIf you want to dropallroles, you can use the environment variableDROP_ALL_ROLES:[instance]
recipe = plone.recipe.zope2instance
environment-vars =
    DROP_ALL_ROLES 1In this case theDROP_ROLESenvironment variable is no longer checked.WithDROP_ALL_ROLESwe change the patches:getRolesandgetRolesInContextalways return a list with a single entry:Anonymous.Theallowedmethod returns True when the required object roles are None or contain Anonymous, otherwise it returns False.You can still login, and the pages will show your name, but you basically cannot make any changes.
Probably you can fill in a form withcollective.easyform, but that should be about the only thing you can do that makes a change to the database.That would be the use case: prevent all (or most) changes to the database.Suggested buildout usageThis is a suggestion on how to properly add this in a buildout.
Note that this focuses on configuring collective.droproles, 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.droproles
# 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 drop roles:
    DROP_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 drop roles:
    DROP_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 drop roles:
    DROP_ROLES 0ftw.upgradeIf you use thebin/upgradescript fromftw.upgrade,
you are automatically authenticated and have the Manager role.
But if this script attaches itself to the public zeoclient above,
the Manager role would be dropped, making the script useless.
We have a patch for this that is active when our other patches are active.
So:bin/upgradeshould work just fine.Note: it willnotwork when you have enabledDROP_ALL_ROLES.SupportIf you are having issues, please let us know.
Contact Maurits van Rees at Zest Software,m.van.rees@zestsoftware.nl.
Or open an issue inGitHub.LicenseThe project is licensed under the GPLv2.ContributorsMaurits van Rees,m.van.rees@zestsoftware.nlChangelog1.0.0 (2021-08-24)Seems to work well, so make a final release.
[maurits]1.0.0b1 (2021-06-15)Initial release.
[maurits]