This is an update on pas.plugins.ldap.

LDAP is Lightweight Directory Address Protocol. This protocol for storing and querying information on users goes back to the eighties. There are various solutions, like OpenLDAP, ActiveDirectory.

There has been LDAP support in Plone for a long time. Products.LDAPUserFolder has been available as basis, replacing the standard user folder. Products.LDAPMultiPlugins wraps it to the PAS API, difficult to install. Products.PloneLDAP integrates is more into Plone, but also difficult to install. plone.app.ldap is a wrapper around this, making it easy to install in Plone. But everything is stacked on top of each other, very difficult to maintain or understand.

We created a complete rewrite: pas.plugins.ldap. We use an abstraction of the LDAP features, in``node.ext.ldap``, Python 2.7 only, using python-ldap, pure Python.

You can get groups and users from LDAP. It maps LDAP attributes to PAS property sheets. Support for caching, for many users, 98 percent test coverage.

Limitations: you cannot add users or groups, only edit them. The underlying library does implement this, so this is a TODO item, although our sites don't actually need it: users are added or deleted in a different system. No multiple (fallback) servers possible. It patches the user portraits, so this may conflict with other patches that you may have.

We have a test layer that uses an OpenLDAP instance.

node.ext.ugm is used, which is a set of interfaces for User and Group Management.

pas.plugins.ldap uses those base packages, configures it using GenericSetup, provides ZMI and control panel forms to configure LDAP.

Supporting 'many' users is tricky, this was solved using money from a fund raiser campaign. Thank you!

Lessons from integrating Pyramid, React, and Plone (and elasticsearch, and Salesforce, and a payment gateway, and...) Quoting from the Plone conference site: "The Volunteer Management System (VMS) is a tool that Jazkarta built for Washington Trails Association to manage volunteer sign-ups for helping maintain hiking trails in the state of Washington. It allows staff to schedule work parties, volunteers to find and register for them, crew leaders to access information about their crew, and land managers to report on work that was done in their region."

The tools you use matter. So use the correct tools.

So at the start, we had the wta.org site, and Salesforce, and vols.wta.org, which was basically a bunch of ten year old scripts.

We could have built everything in Salesforce. It has all kinds of options for doing this, but there are all kinds of restrictions.

We considered Plone. All user accounts were already in here. But we did not need a lot of content management.

On the front-end we used ReactJS. This communicates with Plone for content and with Pyramid for the volunteer management. Pyramid interfaces with Redis, ElasticSearch and Salesforce.

With Pyramid, the view configuration is very close to the actual code, so you don't need a separate zcml file like in Plone. There are no globals, which makes it easier to write isolated tests. Views are easier to test because they return a dictionary instead of a complete html response.

Pyramid is a framework that is good for writing frameworks. We needed to write some infrastructure ourselves, which is nice to do in Pyramid. For example, with config.add_request_method we made a method available on the request to access Salesforce. We registered an exception view to gracefully handle exceptions for either html or json.

With Pyramid, batteries are available for cheap:

• pyramid_chameleon
• pyramid_layout
• pyramid_cachebust
• pyramid_mailer

As special deployment bonus: we were not using a ZODB, so no ZODB cache was needed, so memory requirements were low, so we could use lots of threads to handle moments of high load.

It is not perfect, for example there is no automatic csrf protection like in Plone. Some assembly is required: Plone has lots built-in and in Pyramid you need to do more yourself, for example setting up logging.

We used the py.test framework, which makes it really easy to define fixtures. There is some magic, which not everyone likes. Assertions are easier to debug, giving you more feedback. We used factory_boy to provide fixtures. [See a talk at PyGrunn earlier this year, by Oleg Pidsanyi. Maurits]

We used http://locust.io for load testing.

React was our chosen Javascript framework. I like that it is declarative. You can focus on what is displayed, not how. A lot of changes, like toggling a checkbox, happen automatically.

We have shared navigation between Plone and Pyramid. The navigation is done in Plone, and we created a json endpoint in Plone that Pyramid could call.

We needed to think about Cross Origin Resource Sharing (CORS), with all kinds of headers. These days I would look at plone.rest and how it does this.

Single sign-on. Pyramid redirects you to Plone, where you can login, and with a token you are then logged in to Pyramid.

I am in Berlin via a live video feed. Hello!

In several recent projects with Plone I had a common challenge. The CMS was just one of many parts of the stack. People may view our content on a large computer screen, a mobile phone, or virtual reality glasses, which all need to be handled differently. There are several solutions, like contentful. Some common traits:

• Everything is through the web.
• APIs for various languages

Why was I using Plone for that?

• No more custom PHP development please.
• Lots of things included.
• I am still quite productive with Plone.

Biggest reason:

• I did not look for hosted solutions.

If I build it in Plone, I may be the only one at the company who can maintain it. Not so with a hosted solution.

But: I still love Plone, and want to use it, for good reasons:

• One API endpoint.
• Better control over performance issues.
• Integration with front-end development is essential.

And now I actually have four Plone developers in the team, so that is great. The team is happy with Plone. We use as building blocks:

• plone.restapi. This saved a lot of time.
• plone.app.multilingual
• a policy package
• PyCharm IDE for writing Python
• AWS/Kubernetes/Deis
• Thumbor. Image server over Tornado. Cropping, filters, transforms. We have integrated this in Plone using event subscribers.

Lessons for Plone:

• documentation, documentation, documentation. Everything I did was possible due to documentation.
• More documentation, more documentation, more documentation.
• We need more projects like plone.client.
• We need more commercial offering of headless hosted Plone.

Docker is what virtualenv is for Python. Isolated environment. You have the same environment on Linux/Mac/Windows and development/test/production.

For Plone without Docker you need to install all kinds of libraries, run a buildout, ignore some SyntaxErrors.

For Plone with Docker you can run:

docker run -p 8080:8080 plone

This uses the new official Plone Docker image at https://hub.docker.com/_/plone See information on that page, also on including add-ons or developing. In that case buildout gets run so it can fetch the add-ons.

Always label your Docker volumes to avoid data loss.

You can use a zeoserver:

docker run --name=zeo plone zeoserver

In production you should create your own Docker images, including all add-ons you need. You can use extended_buildout.cfg. For composing your own Dockers, see https://docs.docker.com/compose

When using multiple hosts, you want orchestration. There are several options. We use Rancher. You can use the official Plone Docker image and set several options.

The plan is to use this for continuous delivery, like in the talk by Nejc Zupan.

See various repositories with Docker for the EEA.

See https://github.com/plone/plone.docker for the source of the Plone Docker image.