[Zope-dev] direction

[Hanno Schlichting]

Hi.

On Tue, Jul 5, 2011 at 9:21 PM, Leonardo Rochael Almeida
<leorochael at gmail.com> wrote:
> I guess this is the biggest point of contention. Why does the ZMI have
> to go? Although both Plone and ERP5 strive to gradually replace ZMI
> based configuration with "native" interfaces (native to Plone/ERP5),
> isn't there value in having a minimal OFS browser with the ability to
> Add/Delete/Copy/Cut/Paste objects as a fallback? It doesn't seem to
> conflict with your stated goal:

I think having a minimal database browser is a good idea. I think
something like https://github.com/davisagli/eye is the right starting
point here. I don't want to have anything that lives in the same
process as the rest of the application code. The ZMI is currently like
running phpMyAdmin accessible to the world with the same credentials
and on the same domain as the rest of your application. It's a huge
security risk and pollutes model classes and views in the application
code.

> Or to put it differently, in which way does having a minimalistic OFS
> browser for a ZMI conflicts or hinders Plone's objectives for the
> Zope2 code base?

The ZMI is a highly insecure, completely outdated and user-unfriendly interface.

On the security level, there's no validation of user-input, there's no
XSS and CSRF protection. Anyone being logged into your application who
has ZMI access is susceptible to a large number of attacks. There's
too much of stone-age code based on no-patterns to prevent these
attacks - we can currently only fix them in a tedious process of
finding one exploit after the other. We need a better strategy here -
and the only one I can see is removing the existing ZMI code and
moving any low-level interface to a completely separate codebase and
process.

On the other points, at least Plone tries to use modern web
technologies and for example we just switched to a HTML5 doctype -
having any end-user go to the ZMI and look at a frames-based interface
undermines any marketing message we try to put out about being modern.
And then the ZMI doesn't even do basic things like asking you for
confirmation before removing your entire site and being in almost all
regards a huge usability fail - again completely add odds with Plone's
good end-user usability story. On the code level the ZMI-support code
is mixed into all other model code and has often lead to arcane
developer API's. There's far too many places where a manage_* method
with a request argument is the only way to achieve anything. For
whatever code we'll end up with in two to three years, I want to see
good developer API's that actually make you productive.

I hope this clarifies a bit more, why I feel the ZMI is an arcane
beast that needs to be hunted down sooner than later.

Hanno