Re: [Zope-dev] Re: ZMI / JavaScript brainstorm

2002-04-09 Thread Chris Withers

Charles Y. Choi wrote:
 
 With ZMI, you can create different methods/objects and then edit them.
 The problem is that pretty much every other editor out there doesn't
 know a whit about the types of objects/methods they are creating.
 Does emacs really know the difference between a python method,
 dtml-method, dtml-document, and a page template?  Not likely.

*grinz* You never heard of a PUT_factory? You can (and I do) do this in Zope 2
already.
Think about it, how does Windoze know the difference between a Photoshop file
and a Windows Bitmap?
Zope 2 is even clever than this, I have logic that says if the first character
in a thing is a # then create a PythonScript from it...

As for EMACS, it certainly knows about python (M-x python-mode), and there's
HTML mode for page templates. If you wanna use DTML, you deserve to burn in hell
anyway, so you ain't gonna need an editor ;-)

cheers,

Chris


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: ZMI / JavaScript brainstorm

2002-04-09 Thread Charles Y. Choi

Chris Withers wrote:

Charles Y. Choi wrote:

With ZMI, you can create different methods/objects and then edit them.
The problem is that pretty much every other editor out there doesn't
know a whit about the types of objects/methods they are creating.
Does emacs really know the difference between a python method,
dtml-method, dtml-document, and a page template?  Not likely.


*grinz* You never heard of a PUT_factory? You can (and I do) do this in Zope 2
already.
Think about it, how does Windoze know the difference between a Photoshop file
and a Windows Bitmap?
Zope 2 is even clever than this, I have logic that says if the first character
in a thing is a # then create a PythonScript from it...

As for EMACS, it certainly knows about python (M-x python-mode), and there's
HTML mode for page templates. If you wanna use DTML, you deserve to burn in hell
anyway, so you ain't gonna need an editor ;-)


Yes, and though your PUT_factory override is a great thing, it's an 
unsupported patch: that is,
it's not part of the standard packaging of Zope.  The conventions you 
use (# for PythonScripts)
are not clearly documented.  And as much as I'd love to to chuck DTML, 
 ZPT is still buggy
in 2.5.0 - (try creating a page template for the view method of a ZClass).

As far as emacs goes, it uses file extensions to automatically determine 
what mode to be in.

Brain hurts, must sleep ...

-cc





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: ZMI / JavaScript brainstorm

2002-04-09 Thread Chris Withers

Charles Y. Choi wrote:
 
 Yes, and though your PUT_factory override is a great thing, it's an
 unsupported patch: that is,
 it's not part of the standard packaging of Zope.  

Urm, PUT_factory has been a standard part of Zope for some time now...

 The conventions you
 use (# for PythonScripts)
 are not clearly documented.

That's because I've overridden the default PUT_Factory, hich is one of its
strengths, you can customise it ;-)

  And as much as I'd love to to chuck DTML,
  ZPT is still buggy
 in 2.5.0 - (try creating a page template for the view method of a ZClass).

ZClasses are a waste of time, even more so than DTML. I've not experienced any
bugs in ZPT when used in a sane context.

 As far as emacs goes, it uses file extensions to automatically determine
 what mode to be in.

yes, and? *grinz*

cheers,

Chris


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] RE: [Zope-CMF] Fieldindex searches very slow when anonymous.

2002-04-09 Thread Arnar Lundesgaard

THANK YOU

This worked extremely well, and the site is
almost faster than the squid cache now. :-)

http://www.forskning.no is a major ZOPE site
(for us), that will be released tomorrow noon
local time. This is the first site that uses
our soon to be opensourced TopicMap engine that
builds on CMF. The engine lets CMF handle all 
Topic Map data items, giving us access to CMF
functionality like versioning and workflow.
It should be opensourced when we have time to
clean it up a bit and document it.


 -  Arnar Lundesgaard



 -Original Message-
 From: Tres Seaver [mailto:[EMAIL PROTECTED]]
 Sent: 9. april 2002 05:43
 To: Arnar Lundesgaard
 Cc: [EMAIL PROTECTED]
 Subject: Re: [Zope-CMF] Fieldindex searches very slow when anonymous.

 What is killing your query is the test for effective range 
 of content.  If
 your site does not use the concept (i.e., all your content 
 has 'None' for
 both its effective and expires dates), you can apply the 
 following patch to
 remove the check::
 
 -- patch starts here -
 --- CMFCore/CatalogTool.py4 Jan 2002 19:50:04 -   1.22
 +++ CMFCore/CatalogTool.py9 Apr 2002 03:42:14 -
 @@ -186,7 +186,7 @@
   user = _getAuthenticatedUser(self)
   kw[ 'allowedRolesAndUsers' ] = 
 self._listAllowedRolesAndUsers( user )
 
 -if not _checkPermission(
 +if 0 and not _checkPermission(
   CMFCorePermissions.AccessInactivePortalContent, self ):
   base = aq_base( self )
   now = DateTime()
 -- patch ends here ---
 
 Tres.
 -- 
 ===
 Tres Seaver[EMAIL PROTECTED]
 Zope Corporation  Zope Dealers   http://www.zope.com
 
 


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: ZMI / JavaScript brainstorm

2002-04-09 Thread Nicola Larosa

 ZClasses are a waste of time, even more so than DTML.

Words of comfort. :^) Nice never having spent the time to learn 'em.


 I've not experienced any bugs in ZPT when used in a sane context.

Same here, after several months' usage.


-- 
Two witches watch two watches. Which witch watched which watch?

Nicola Larosa - [EMAIL PROTECTED]



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] ZClasses useful! [Was: ZMI / JavaScript brainstorm]

2002-04-09 Thread Stefan H. Holek

At 09.04.2002 10:46 +0100, Chris Withers wrote:

ZClasses are a waste of time, even more so than DTML.

Chris, please stop that dissing of ZClasses. They are *very* useful indeed!

No, not so much for the seasoned Python/Zope coder, but for the content 
manager (remember, Zope is a CMS after all!). I have successfully taught 
ZClasses to people who would not easily grasp how this (disk-based) Python 
stuff works, simply because they are content managers not software 
developers. And, IMO, they should not even need to care.

I sure hope this part of Zope's audience is not forgotten in Zope3. I have 
always considered it a strength of Zope to allow unskilled users to 
create and deploy dynamic websites.

We can fight this out at the BBQ if you like ;-)
Stefan

--
BLOWFISH n. - Preference for beef



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] ZClasses useful! [Was: ZMI / JavaScript brainstorm]

2002-04-09 Thread Toby Dickenson

On Tue, 09 Apr 2002 12:56:38 +0200, Stefan H. Holek
[EMAIL PROTECTED] wrote:

ZClasses are a waste of time, even more so than DTML.

Chris, please stop that dissing of ZClasses. They are *very* useful indeed!

No, not so much for the seasoned Python/Zope coder

Even for the seasoned Python/Zope coder, ZClasses have a sweet spot
that cant be beaten by any other zope technology.



Toby Dickenson
[EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Re: [Zope-CMF] Fieldindex searches very slow when anonymous.

2002-04-09 Thread Tres Seaver

Arnar Lundesgaard wrote:
 THANK YOU
 
 This worked extremely well, and the site is
 almost faster than the squid cache now. :-)
 
 http://www.forskning.no is a major ZOPE site
 (for us), that will be released tomorrow noon
 local time. This is the first site that uses
 our soon to be opensourced TopicMap engine that
 builds on CMF. The engine lets CMF handle all 
 Topic Map data items, giving us access to CMF
 functionality like versioning and workflow.
 It should be opensourced when we have time to
 clean it up a bit and document it.

Excellent -- I'm glad that helped.  Note that for Zope 2.6, we have
added some new index types to deal more directly with such problems:

   - DateIndex:  a FieldIndex which knows it is for DateTimes,
 and indexes a much more efficient (both space and time!)
 representation;

   - DateRangeIndex:  indexes a pair of DateTimes, allowing the specific
 query you had trouble with to go *much* faster;

   - TopicIndex:  indexes values which pass user-defined filters, effectively
 precomputing a frequently-used catalog query.

Tres.

-Original Message-
From: Tres Seaver [mailto:[EMAIL PROTECTED]]
Sent: 9. april 2002 05:43
To: Arnar Lundesgaard
Cc: [EMAIL PROTECTED]
Subject: Re: [Zope-CMF] Fieldindex searches very slow when anonymous.

What is killing your query is the test for effective range 
of content.  If
your site does not use the concept (i.e., all your content 
has 'None' for
both its effective and expires dates), you can apply the 
following patch to
remove the check::

-- patch starts here -
--- CMFCore/CatalogTool.py4 Jan 2002 19:50:04 -   1.22
+++ CMFCore/CatalogTool.py9 Apr 2002 03:42:14 -
@@ -186,7 +186,7 @@
  user = _getAuthenticatedUser(self)
  kw[ 'allowedRolesAndUsers' ] = 
self._listAllowedRolesAndUsers( user )

-if not _checkPermission(
+if 0 and not _checkPermission(
  CMFCorePermissions.AccessInactivePortalContent, self ):
  base = aq_base( self )
  now = DateTime()
-- patch ends here ---

Tres.
-- 
===
Tres Seaver[EMAIL PROTECTED]
Zope Corporation  Zope Dealers   http://www.zope.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]

2002-04-09 Thread Chris Withers

Stefan H. Holek wrote:
 
 At 09.04.2002 10:46 +0100, Chris Withers wrote:
 
 ZClasses are a waste of time, even more so than DTML.
 
 Chris, please stop that dissing of ZClasses. They are *very* useful indeed!

If you enjoy pain and suffering and no upgrade path.

I will not stop dissing them until people stop using them and then complaining
when they break, don't do what they want or behave unexpectedly.

 No, not so much for the seasoned Python/Zope coder, but for the content
 manager (remember, Zope is a CMS after all!). 

Use the Types Tool in the CMF, its a lot closer to what ZClasses wanted to be.

 I sure hope this part of Zope's audience is not forgotten in Zope3. I have
 always considered it a strength of Zope to allow unskilled users to
 create and deploy dynamic websites.

Yup, I have the same fear for Zope 3, but trying to stand up for one of the most
difficult to learn and use pieces in the whole Zope architecture is not the way
to go about it...

 We can fight this out at the BBQ if you like ;-)

...you're buying the beers though.

Chris


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]

2002-04-09 Thread Martijn Jacobs

 I will not stop dissing them until people stop using them and then
complaining
 when they break, don't do what they want or behave unexpectedly.

What's your efford on this task? If people like to use them, let them!
It's not up to you to decide for THEM what's best or not. The choice for
YOURSELF not to use them is just as fair as other peoples choices.



martijn.






___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Toby Dickenson

Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation

This proposal from Itamar has been up on dev.zope.org for a while, proposing 
a way for a registered type to control whether or not it can be added to a 
container, or a per-container basis.

I now have an implementation of this in CVS in the toby-metatypes-branch. I 
propose this goes into zope 2.6. Any comments?

(Ive CCed everyone who has commented on the proposal; I hope thats OK)


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]

2002-04-09 Thread R. David Murray

On Tue, 9 Apr 2002, Martijn Jacobs wrote:
  I will not stop dissing them until people stop using them and then
 complaining
  when they break, don't do what they want or behave unexpectedly.

 What's your efford on this task? If people like to use them, let them!
 It's not up to you to decide for THEM what's best or not. The choice for
 YOURSELF not to use them is just as fair as other peoples choices.

Actually, we find on #zope-dev that if we steer newbies away from
zclasses and toward Products to begin with, they thank us later,
and it reduces our support burden.  The same can be said for this
list.  Chris does tend to be a little vociferous about it grin.

We aren't generally dealing with content devloper types in either place.

Learning ZClasses (because that's what was documented in the manual
at the time) rather than going straight to python products was
the *worst* mistake I made in starting to use Zope, myself.  It
probably set me back six to nine months.

--RDM



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Casey Duncan

IMO, this comes at this at the wrong direction.

Objects should not decide whether they can be added to a given folder, 
the folder should be the one that makes that decision.

It gives me the heebie geebies to think that every time the add list is 
rendered, a whole slew of class methods are potentially called to 
determine what gets put there.

This also invokes my ui chaos alarm. It gives things such arbitrary 
ability to dynamically affect the ui, that it may cause mass confusion 
by users who can't understand why an object is addable in one folder but 
not in another (seemingly identical) folder. Granted, this is somewhat 
possible right now (using permissions), but this pushes it a bit over 
the edge for me. It smells too much like magic.

-Casey

Toby Dickenson wrote:
 Re: http://dev.zope.org/Wikis/DevSite/Proposals/RestrictedCreation
 
 This proposal from Itamar has been up on dev.zope.org for a while, proposing 
 a way for a registered type to control whether or not it can be added to a 
 container, or a per-container basis.
 
 I now have an implementation of this in CVS in the toby-metatypes-branch. I 
 propose this goes into zope 2.6. Any comments?
 
 (Ive CCed everyone who has commented on the proposal; I hope thats OK)





___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



RE: [Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Brian Lloyd

 IMO, this comes at this at the wrong direction.
 
 Objects should not decide whether they can be added to a given folder, 
 the folder should be the one that makes that decision.
 
 It gives me the heebie geebies to think that every time the add list is 
 rendered, a whole slew of class methods are potentially called to 
 determine what gets put there.

I think (correct me though, if I'm wrong!) that Toby 
actually implemented the suggestion that Jim made on 
the comments page of the proposal (add a filter to the 
meta type info, allowing products to do this without 
killing performance).

We need to find a reasonable place to document the API 
addition for this before merging it.



Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716   
Zope Corporation   http://www.zope.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Itamar Shtull-Trauring

Toby Dickenson wrote:

 (Ive CCed everyone who has commented on the proposal; I hope thats OK)

Could everyone stick to zope-dev only? One copy of each email is enough ;)



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Casey Duncan

After reading the discussion page I feel a bit more comfortable with it.

I do see an undesireable increase in the entropy of the ui, however. 
This could be offset by careful use of this feature, of course. In fact 
good use of it could reduce some of the clutter in the add list. For 
instance, singleton classes might automatically hide themselves if they 
find an instance of themselves somewhere.

As Chris M says: The problem is dynamism ;^)

-Casey

Brian Lloyd wrote:
[snip my knee jerk reaction]
 
 I think (correct me though, if I'm wrong!) that Toby 
 actually implemented the suggestion that Jim made on 
 the comments page of the proposal (add a filter to the 
 meta type info, allowing products to do this without 
 killing performance).
 
 We need to find a reasonable place to document the API 
 addition for this before merging it.
 
 
 
 Brian Lloyd[EMAIL PROTECTED]
 V.P. Engineering   540.361.1716   
 Zope Corporation   http://www.zope.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Chris Withers

Brian Lloyd wrote:
 
 I think (correct me though, if I'm wrong!) that Toby
 actually implemented the suggestion that Jim made on
 the comments page of the proposal (add a filter to the
 meta type info, allowing products to do this without
 killing performance).

...but hasn't this problem already been solved with the wierd-interface-filter
thing that Andreas did for the PluginIndexes stuff?

cheers,

Chris


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] RedstrictedCreation proposal

2002-04-09 Thread Toby Dickenson

On Tue, 9 Apr 2002 10:57:04 -0400, Brian Lloyd [EMAIL PROTECTED]
wrote:

 IMO, this comes at this at the wrong direction.
 
 Objects should not decide whether they can be added to a given folder, 
 the folder should be the one that makes that decision.

Zope can already do that. Check out how ZCatalog.Indexes requires all
of its contained items to implement the PluggableIndex interface.

That works well when you have a special folder type, but it doesnt
help when you want to control whether special objects can be added to
ordinary folders.

 It gives me the heebie geebies to think that every time the add list is 
 rendered, a whole slew of class methods are potentially called to 
 determine what gets put there.

One function per type, if it was specified during registration. This
isnt configurable through-the-web.

I think (correct me though, if I'm wrong!) that Toby 
actually implemented the suggestion that Jim made on 
the comments page of the proposal (add a filter to the 
meta type info, allowing products to do this without 
killing performance).

Thats correct. I changed the parameter name from Jim's suggestion;
'filter' to 'container_filter'.

We need to find a reasonable place to document the API 
addition for this before merging it.

Im happy to keep any documentation up to date, provided it is already
up to date. Is there any more than the docstring? Suprisingly, I
couldnt find any at
http://www.zope.org/SiteIndex/search?text_content=registerClass



Toby Dickenson
[EMAIL PROTECTED]


___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] [RFClet]: What about the request method and the client side trojan?

2002-04-09 Thread Oliver Bleutgen

The issue of client side trojan recently came to my mind again.
Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan
I found nothing new since Oct. 2001, so I thought I bring up the issue 
again, maybe it's something which could be taken care of for zope = 2.6.

I wrote something about that at the wiki, but let me repeat my proposal.

I think zope's management methods (the potentially destructive ones) 
should not accept REQUESTs with REQUEST_METHOD GET.

This is in accordance with the http/1.1 rfc (reposted from the wiki):

Implementors should be aware that the software represents the user
in their interactions over the  Internet, and should be careful  to
allow the user to be aware of any actions they might take which may
have  an  unexpected  significance  to  themselves  or  others.  In
particular,  the convention   has  been  established  that the  GET
and HEAD methods SHOULD  NOT  have  the significance of  taking  an
action   other  than   retrieval.  These   methods  ought   to   be
considered  safe.  This allows  user agents  to  represent  other
methods, such as  POST, PUT and  DELETE, in a special way, so  that
the user is made aware of the fact that a possibly unsafe action is
being requested.


The win would be that disabling javascipt would make a client save from 
this form of attack, AFAIK, OTOH I can't think of anything which would 
break ATM.

cheers,
oliver



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



RE: [Zope-dev] [RFClet]: What about the request method and the client side trojan?

2002-04-09 Thread Brian Lloyd

 The issue of client side trojan recently came to my mind again.
 Looking at http://www.zope.org//Members/jim/ZopeSecurity/ClientSideTrojan
 I found nothing new since Oct. 2001, so I thought I bring up the issue 
 again, maybe it's something which could be taken care of for zope = 2.6.
 
 I wrote something about that at the wiki, but let me repeat my proposal.
 
 I think zope's management methods (the potentially destructive ones) 
 should not accept REQUESTs with REQUEST_METHOD GET.
 
 This is in accordance with the http/1.1 rfc (reposted from the wiki):

 snip RFC citation...
 
 The win would be that disabling javascipt would make a client save from 
 this form of attack, AFAIK, OTOH I can't think of anything which would 
 break ATM.

While I don't necessarily disagree about making GETs idempotent, 
this still doesn't make you safe, even with JS turned off.

A quick example: images can be used as form submit buttons. If 
I can get you to visit a page and click on my innocent looking 
image... you're done :)

This is hard, hard, problem. While some good ideas have been 
proposed, there is not really a quick fix that doesn't have 
some downside that some group somewhere considers a 
showstopper :(


Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716   
Zope Corporation   http://www.zope.com




___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



[Zope-dev] Speaking of 2.6...

2002-04-09 Thread Brian Lloyd

...I sent out a note a while ago now trying to scare up 
some ideas on how to vet the current list of 2.6 proposals 
and get to a final plan. I didn't get much (any?) response :(

For a couple of things that were ready to go and fairly non
controversial (like Toby's unicode work), I put on the BDFL 
hat and said merge it!.

But there are still a lot of things on the proposed features 
that are undone, and some that are controversial enough that 
we need to get to closure on them.

I'll volunteer to convert the current proposed feature list 
into a draft plan, where the conversion boils down to 
adding some columns to the table:

Proposal - name and link to the proposal

Resources - who is working on it

Committed - Y/N whether the volunteers have committed to have
the implementation and docs done by the first week
in June. I'll fill in what I know has been committed
to, people can update this (or let me know and I'll 
do it), and anything that doesn't get a 'Y' in a 
reasonably short time will be put in the cooler.

Vetted - Y / N whether the community and / or the relevant BDFLs
 have come to some agreement on whether it *should* be 
 done. The list of items without a 'Y' will be our next 
 order of business. Getting to closure on those either 
 via the list, IRC, or whatever is the main block on the 
 critical path.

Status - Complete or incomplete 


I've taken a first stab at this. I've set the committed to 'Y' 
for those things that I know I've gotten commitments for. For 
those set to 'N', please let me know if you can commit to the 
date (or change it yourself in the wiki).

The updated plan is at:

http://dev.zope.org/Wikis/DevSite/Projects/Zope2.6/ProposedFeatures


Once we get the commitments up to date, we can start wrangling 
with the vetting...


Brian Lloyd[EMAIL PROTECTED]
V.P. Engineering   540.361.1716   
Zope Corporation   http://www.zope.com



___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-Coders] Re: [Zope-dev] Speaking of 2.6...

2002-04-09 Thread Myroslav Opyr

Brian Lloyd wrote:

 Both me and Myroslav Opyr [EMAIL PROTECTED] are quite
 commited to do the proposed Object Links/References. Although
 from the emails we exchanged with you, I would've guessed that
 it was one of the controversial enough to be a Vetted item :-)

 Anyways I'm commited to do it. I do agree with your argument about
 link semantics but, at least for me, a link/reference is a link, and the
 semantics are perfectly defined i.e its not a RedirectObject.

 As in Unix, a hard link has different semantics from a soft link. I'm
 thinking of the hard link semantics. 

I guess that what I was getting at is that the semantics 
for this need to be spelled out in detail so that we can 
make sure that they make sense before something like this 
goes in.

Ok. Let's find out what we have and what we want. First of all we have 
strict hierarchy in ZODB where each object appears only once in the 
tree. Thus to access to an object it is only one way from root down to 
an object through containers. All security in Zope is based on that 
pattern. I am omitting Acquisition machinery to simplify (and I do not 
see it clearly in the context here).

The idea is to allow user to specify several points of presence (pop) 
for an object. Does this break security? Probably yes, but in what case? 
If an object from higly secure envionment appeared somewhere in 
Anonymous zone, what then? Yes, Anonymous is able to alter object. But 
there was reason for that! Is Anonymous able to get out of the shared 
object to secure environment? No in no simple way. Sure if an object was 
DTML and Anonymous placed trojan horse in the script and someone from 
secure environment executed the code then we run in a problem. But we 
can warn user! And we have a lot of Restricted... techniques, maybe 
one can be applied here?

Comparing it to Unix hard links is fine, but Unix doesn't 
use Acquisition to handle security, so the comparison is 
not apples-to-apples :) We need to spell out the exact semantics 
(*especially* wrt security, but also in terms of its effect on 
ZODB identity semantics, effects on undo, etc.)

Ok. I am not too well in English but I'll try to do my best. If it is 
not hard for you give several words of explanation of ZODB identity 
semantics and effects on undo, not everything is clear for me.

Security in particular is very concerned with *containment* 
path (rather than just acquisition path) in order to prevent 
stealing access through acquisition wrappers. Having objects 
with more than one place may introduce much the same problem, 
so we'll need to write up in detail the effects on the security 
machinery or its application to domain objects (or if the security
machinery does not need to change, we need to spell out why).

Why we are not willing to allow such scenario? AFAIK there was and are a 
lot of concernes refarding soft- and hardlinks in /tmp folder, with 
sticky bit, etc... But they are usually solved with different means. 
Yes, Zope and ZODB is much more complex. But why we have to limit 
ourselves because something is difficult. Why not mark the feature as 
experimental (red button, a lot of warnings, for instance) and make it 
available to SuperManager only ;)

I'd be glad to get feedback, thanks,

Myroslav
-- 
Myroslav Opyr
zope.net.ua http://zope.net.ua/ ° Ukrainian Zope Hosting
e-mail: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
cell: +380 50.3174578






___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )



Re: [Zope-dev] Re: ZClasses useful! [Was: ZMI / JavaScript brainstorm]

2002-04-09 Thread Andy McKay

 What's your efford on this task? If people like to use them, let them!
 It's not up to you to decide for THEM what's best or not. The choice for
 YOURSELF not to use them is just as fair as other peoples choices.

Sure but many people ask more experienced developers for advice. I agree
saying ZClasses suck totally is unhelpful. For people who dont know coding
or want to do quick prototyping they have a place. However if someone asks
me how to do a product, I normally give them the choice: use ZClasses but I
would strongly recommend using a Product etc (and then be ready with the
reasons why which is the next question).

Unfortunately people deciding the right and wrong ways for other people to
code is a trait sometimes found in Python / Zope world. But dont get me
started on that :)
--
  Andy McKay






___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://lists.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://lists.zope.org/mailman/listinfo/zope-announce
 http://lists.zope.org/mailman/listinfo/zope )