ZEO Client space was: [Zope] Prerequisites for a desktop IDE, or any desktop app w/Zope

[sean.upton@uniontrib.com]

This makes a lot more sense now; Your client just 'borrows' Zope security
mechanisms, and uses them; your GUI platform is Zope with a new UI.  In the
case of an IDE, this makes sense.

The security thing, though, is still a concern, because in a typical
enterprise application, you want to be able to grant differing levels of
trust and privileges to certain folks; and if they all access the same ODB,
what (for example, in the case of an enterprise KM portal) prevents a clever
user (let's say, a Python programmer in the company's IT dept) from being
able to bypass the client security mechanism and get access to HR or payroll
data that he/she is not supposed to see?  

You could do host-based security, use a firewall, and limit access in
certain ways, but this still won't get you what you need.  You could use
encryption, but the issues are still the same.  In most RDB-based client
apps, a client libraries are set up on the users' machines by company IT
staff, who set passwords for certain types of access; control over
authentication mechanisms happens on a server, which is under control of a
restricted group of people.  

I guess, if you are just looking for applications that access data and call
methods written in Zope, XML-RPC would still be ideal, and have the security
features that would be needed.  

There is another advantage to using XML-RPC: XML transactions can be
brokered.  Suppose we are trying to create a newspaper editorial CMS-like
system, which stores news stories for different "desks" at a newspaper:
['news', 'features', 'sports'].  You have a diverse web farm of 6 nodes,
composed of 3 clusters ZEO clients (2 machines each, all nodes access a
single ZSS); each of these ZEO groups handles content and databases for each
"desk."   All of these desks access content through XML-RPC from fat
clients.  In this case, we want to be able to create a single virtual server
out of these; use a product like an Intel 7210 XML accelerator, and you can
loadbalance+direct traffic to the correct server by creating some XPath
queries of the request XML to see what database they are trying to access,
or what method they are calling, etc.  This would also allow us to speed
things up and do things like authenticate stuff in the "sports" database off
of one LDAP server set up for sports writers, and "news" off another.  I
understand that this wouldn't address parsing and marshalling latency, but
it seems like a good way to have a big application with many GUI clients set
up.

I know that this way we don't have access to as rich of an object set, or
acquisition, etc, but it seems like for most GUI apps, this would be a
reasonable thing to give up (for the time being, at least) to have the
flexibility and simplicity of using XML-RPC.  So, some might ask the
question: why create a client that simply treats Zope remote methods as a
"dumb" data source?  I'm not sure that a dumb transport necessarily makes
for an unintelligent application; it just means the application is a little
bit more autonomous from Zope (which could either be good or bad)...

Sean

-----Original Message-----
From: Michel Pelletier [mailto:michel@digicool.com]
Sent: Thursday, May 24, 2001 9:25 PM
To: tim@freepm.org
Cc: zope@zope.org
Subject: Re: ZEO Client space was: [Zope] Prerequisites for a desktop
IDE, or any desktop app w/Zope


On Thu, 24 May 2001, Tim Cook wrote:

> Michel Pelletier wrote:
>
> > XMLRPC could do this, but I'm afraid it would be seriously
> > limited.  XMLRPC is very useful, but it does not map as well as it could
> > onto the python object model.  I would prefer to see a GUI client
running
> > in the same process space as a ZEO client, this way the GUI client could
> > do everything that Zope could do and re-use alot of the existing
> > interfaces (like security, acquisition, script objects, etc).
> >
>
> Michel,
> I took this off list because it was off topic for the thread. But
> feel free to Cc it back if you feel it's important.  I think it
> was covered a few weeks ago on the -dev list but couldn't locate
> it.

It's not off topic so I'm cc:ing the list.

> Anyway, the question is: I thought I had read that using ZEO
> basically by-passed the Zope security model? Maybe I was thinking
> of direct ZODB access?

This is a good question.

Using ZEO does bypass the Zope security model, but then again, Zope
bypasses the Zope security model.  Zope is, essentially, a client that
implements an application on top of a persistent database.  Why can't your
client do the same thing?  Zope enforces security upon its users using
tested, re-usable interfaces.

You're should essentially change the user interface to the Zope core code
by making it call wxPython widgets or whatever instead of spewing HTML to
a browser over a socket.  If this GUIfied ZEO client ran on the same
machine as the server, it would actually be safer than a "real" Zope
ZEO client, which is exposed to the web.

We use ZEO clients to access Zope through many different interfaces, not
necessarily all of them over a network, or running in a context we don't
trust.  We use ZEO clients to debug zope from the command line, to serve
just FTP or a monitor server, and each different way of doingit is just a
shim on top of the core Zope interfaces.

By going with xml-rpc, you'll be shoving *very* rich interface semantics
of a full blown windowing sytem down the tiny semantic straw of xml-rpc,
to try and manipulate interfaces that were originally indented to be used
by medium to poor semantic HTML interfaces.  If you use a ZEO client,
there are no bottle necks.  You could render the object system in 3D
OpenGL if you wanted to, and still enforce the user.

Jerome's ZShell script shows how this can be done safely.  His shell is
essentialy just another interface to the Zope core code.  It would be very
dangerous if it did not use Zope's security API to restrict its actions.

In zshell's case, the interface is really simple, a command line. It is
probably not as safe to to grant access to this command line over
unprotected networks. and it would be unsafe to expose a GUIfied ZEO
client to unprotected networks, but this is easily mitigatable with things
like ssh or ssl.

-Michel



_______________________________________________
Zope maillist  -  Zope@zope.org
http://lists.zope.org/mailman/listinfo/zope
**   No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope-dev )