[Zope-dev] A Virus was Detected in a document you sent.

2004-06-25 Thread donotreply
If you did not send a message to onyxes.com you were probably the victim of
e-mail spoofing.
   Email spoofing
 Mass-mailing worms often use a technique called spoofing.
When a mass-mailing worm
 performs its email routine, it randomly selects an email
address from somewhere on the
 infected computer. It then uses that random email address in
the From field, and
 emails an infected email to other email addresses it finds on
the infected computer.
 There have been many cases reported where users of computers
receive complaints that
 they sent an infected message to someone. Because the
mass-mailing worm does not use
 the email address of the infected computer in the email it
sends, there is no way to
 know where the infected email came from. (Symantec Anti-Virus
Research Center website)
We recommend that you check your computer for virus. Below is the
information:


The infected component in the scanned document was deleted.


Violation Information:
The attachment message.pif contained the virus [EMAIL PROTECTED] and was
deleted.
The filename extension of attachment message.pif violated the content
filtering rule Delete Attachment and was deleted.



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


[Zope-dev] Undeliverable Mail

2004-06-25 Thread Postmaster
Requested action not taken: virus detected

Original message follows.

Message-ID: [EMAIL PROTECTED]
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: SPAM: something for you
Date: Fri, 25 Jun 2004 06:51:22 -
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary=SomeRandomStuffGoesHere
X-RBL-Warning: REVDNS: This E-mail was sent from a MUA/MTA 212.54.103.34 with no 
reverse DNS entry.
X-Declude-Sender: [EMAIL PROTECTED] [212.54.103.34]
X-Note: This E-mail was scanned by Declude JunkMail (www.declude.com) for spam.
X-Spam-Tests-Failed: REVDNS, SPAMHEADERS, WEIGHT10

This is a multi-part message in MIME format.

--SomeRandomStuffGoesHere
Content-Type: text/plain;
charset=iso-8859-1
Content-Transfer-Encoding: 7bit

You have spam!

Subject:something for you
From:   [EMAIL PROTECTED]
Tests Failed:   REVDNS, SPAMHEADERS, WEIGHT10

To view the E-mail, just click the attachment.



--SomeRandomStuffGoesHere
Content-Type: message/rfc822;
name=spam.eml
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=spam.eml

Received: from orotech.net [212.54.103.34] by orotech.net
  (SMTPD32-8.12) id AB35B3D00CA; Fri, 25 Jun 2004 02:50:29 -0400
X-AntiVirus: Checked by Dr.Web (http://www.drweb.net)
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: something for you
Date: Fri, 25 Jun 2004 09:49:37 +0300
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=00380126
Message-Id: [EMAIL PROTECTED]

--00380126
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

that is bad

--00380126

--00380126--

--SomeRandomStuffGoesHere--


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


[Zope-dev] Re: zope-dev list policies

2004-06-25 Thread Godefroid Chapelle
Tres Seaver wrote:
Leonardo Rochael Almeida wrote:
On Mon, 2004-06-21 at 11:59, Casey Duncan wrote:
-1 on changing the list policy. I read and post to all of the public
lists through Gmane, which won't work if the policy is changed.

I might be wrong but I think this is incorrect. From the headers of this
message you sent it's possible to see that you sent it thru gmane, yet
the From: address is your zope.com address, so you should not have a
problem posting thru the list this way.

I think you got a direct reply (but could be wrong).  I got the original 
mail bounced to me just now.

Tres.
This surprises me.
I am administring plone-i18n mailing list. Non members cannot post. I 
always post through gmane and my messages get accepted !

Further, I think Mohsen has a very good point when he mentions the fact 
that spam pollutes the archives !

IOW, I think we really could make advantage of Non-members not allowed 
on zope lists.

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


[Zope-dev] Zope Collector issue #1384

2004-06-25 Thread Simon Eisenmann
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I just submitted issue #1384 to zope.org's collector but got this error
message:
Email notice error: '(110, 'Connection timed out')'
Therefore i send the note of this collector issue to the dev list.
See the issue at:
http://zope.org/Collectors/Zope/1384
Cheers,
~ Simon
*** snip ***
len(LazyCat) doesnt work when tried to read more elements as in the
LazyCat before:
~From time to time we had some problems with doing Zcatalog based OR
searches. To do this we simply add one catalog result to the other. An
addition of LazyMap's produces a LazyCat object. In some conditions our
application raised AttributeError: LazyCat instance has no attribute
'_seq'. Today i looked into this in detail and found the problem in the
LazyCat implementation.
So the problem is that when you iterate over more LazyCat list elements
that there are actually in the list an IndexError is raised. This is
fine of course. But afterwards you are no longer able to get the length
of this LazyCat, because the error above is raised. You need to read the
length of a LazyCat _before_ you have code which probably could raise an
IndexError of this list.
To test this behavior use the following script on a ZCatalog:

catalog = context.portal_catalog
res1 = catalog(SearchableText=admin)
res2 = catalog(SearchableText=icoya)
res = res1 + res2
for x in range(6):
~try: print x, x, res[x]
~except: pass
print len, len(res)
return printed

In this case the real length of the res LazyCat is 5 .. so i iterate to
6 which raises an IndexError. Afterwards it's no longer possible to
retrieve the length of this (now borked) LazyCat. If i had read the
length before the iteration, all works perfectly, since the
implementation remembers the len if it was computed once.
So if this is to be fixed then the implementation of the LazyCat length
method has to be changed slightly to check for the missing _seq
attribute and then use the self._data for length retrieval.
*** snip ***
- --
Simon Eisenmann
[ mailto:[EMAIL PROTECTED] ]
[ struktur AG | Junghansstrae 5 | 70469 Stuttgart ]
[ T. +49.711.896656.68 | F.+49.711.89665610 ]
[ http://www.struktur.de | mailto:[EMAIL PROTECTED] ]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA2+yqcKXkdvrBGTARAnZYAKCinwA7HLamr0ZTzVQNgi8oCpkh+QCeK31k
zqaOTHEqiUN9D8hYxgq4AwM=
=kEId
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Email marketing

2004-06-25 Thread [EMAIL PROTECTED]



Email Marketing !

 We offer you e-mail addresses databases
for advertisement mailing; we sell databases
also carry out mailing and hosting for the
advertising projects. 

Products

World Email Lists . Their validity
and originality are verified. Details please go to our website

Country or area total emails and price

America   175 Million Email
Address 
Europe156 Million Email
Address 
Asia 168 Million
Email Address 
China(PRC)  80 Million Email Address

HongKong   3.25 Million Email
Address 
TaiWan2.25 Million
Email Address 
Japan27 Million
Email Address 
Australia  6 Million Email Address

Canda10 Million
Email Address 
Russia38 Million Email
Address 
England   12 Million Email
Address 
German   20 Million
Email Address 
France38 Million Email
Address 
India12 Million
Email Address 
other Country or Area  

-
 
 

 
 
Category Name total emails 

Apparel, Fashion, Textiles and Leather 4,654,565

Automobile  Transportation  
6,547,845 
Business Services
 
 6,366,344 
Chemicals 
 
3,445,565 
Computer  Telecommunications 
   654,655 
Construction  Real Estate  
3,443,544

Consumer Electronics   
 
1,333,443 
Energy, Minerals  Metals  
 6,765,683

Environment 
 
   656,533 
Food  Agriculture   
 
 1,235,354   
 

Gems  Jewellery   
 
  565,438 
Health  Beauty   
 
   804,654 
Home Supplies
 
   323,232 
Industrial Supplies   
 
415,668 
Office Supplies
 
  1,559,892 
Packaging  Paper  
 
  5,675,648 
Printing  Publishing   
 
6,563,445 
Security  Protection   
 
5,653,494 
Sports  Entertainment  
 
3,488,455 
Toys, Gifts and Handicrafts 
2,135,654

-

All of Country email lists + email sender
express +add url express + etrae express+Ebook
-



Send Your Ad to Millions 

5 million bulk email 
50 million bulk email 
100 million bulk email 
200 million bulk email 

Imagine emailing 500,000 recipients and 1
out of every 1000 orders your product, that's
500 new orders!
* We go all-out to make sure our customers
are completely satisfied 
* If any emails fail to make delivery, we
replace them free of charge
* 100% Spam free, rest assured you will not
be accused of spamming
* Almost all of our emails are sent to valid
email addresses
* No software required, we do all the mailing
from our own server
* Don't be fooled in signing up with similar
sites offering services that cannot compare
to ours
* Get the most bang for your buck with bulk
email advantage!
-



Details go to website


Thank you!

the silver star internet information company

copyright2004-2005 all reserved



remove please email: [EMAIL PROTECTED]


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


[Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
On Sat, 19 Jun 2004 20:14:47 -0300
Leonardo Rochael Almeida [EMAIL PROTECTED] wrote:

 On Wed, 16 Jun 2004 11:16:55 +0200
  Eric Brun [EMAIL PROTECTED] wrote:
  
   
   
   Hi,
   
   I have a problem with 'getObject' method of CatalogBrains class on
   Zope271b1 : it's return None. But with a Zope2.7.0 my object is
   correctly find and returned. The permissions are right.
  
 
 Em Qua, 2004-06-16 às 11:28, Casey Duncan escreveu:
  getObject was refactored recently and its security was increased. It
  uses restrictedTraverse() now, which means that you need access to
  all of the enclosing folders as well as the object. Before, no
  security checking was performed by getObject.
  
  I suspect you do not have access to one of the containing folders.
 
 I certainly hope he'd get a permission error instead of silent 'None'
 for '.getObject()' in this case or I'd consider it a bug :-)

Me to, except that changing this behavior will break existing apps.
There is an implicit contract the getObject should not raise errors.
Perhaps this means we need a different method with better behavior.
Somehow that doesn't seem all that appealing, however.

-Casey

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


[Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
On Thu, 24 Jun 2004 19:04:55 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:

 Casey Duncan wrote at 2004-6-18 09:58 -0400:
  ...
 Security was tightened for getObject recently as part of a general
 refactor of that code. I am happy to consider whether the security is
 too tight, in which case it could be backed off a bit.
 
 I think, you should only require access rights to the object itself
 and not to all folders from the root to the object.
 
 It is not uncommon that upper levels are more restricted than
 subhierarchies. This is what Zope's URL traversal
 allows: Only the object identified by URL traversal is
 accessed checked.
 
 That ZCatalog identifies objects by physical path is an implementation
 artifact. It should not make it impossible to access an
 object via the catalog that otherwise can be accessed without
 problem.
 
  ...
 For hysterical raisins, REQUEST.traverse() does not behave this way.
 It instead checks only the final object traversed.
 That's a good behaviour...

Except when it isn't ;^) OTOH it is closer to the behavior of getObject
in 2.7.0. Ironically it used to use restrictedTraverse long ago...

-Casey

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


[Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
On Thu, 24 Jun 2004 09:59:30 +
Santi Camps [EMAIL PROTECTED] wrote:

 Security was tightened for getObject recently as part of a
 general refactor of that code. I am happy to consider whether the
 security is too tight, in which case it could be backed off a bit.
 
 Previously getObject performed no security checks and returned
 objects for catalog results regardless of security permissions (it
 used unrestrictedTraverse). I switched it to use
 restrictedTraverse which checks security all the way down on all
 of the containing folders and on the final object itself. This is
 how path expressions work, for example.
 
 I think this new security checks could be a problem in some cases. 
 They are Ok when using restricted code, but from trusted code I'm not
 sure that force to use restrictedTraverse could be considered a goal.

That is a good point, however since getObject is not itself a protected
method, and cannot tell whether it is being called by restricted code,
it must always do its own checking.

 For instance, imagin an application with employees of one department
 managing dossiers with economic data inside.  Employees of accounting
 department shouldn't have access to these dossiers objects, but they
 need to obtain some reports with a sum of all dossiers economic data. 
  So, accounting department users shouldn't have access to dossiers
  objects, but from reports trusted code these dossiers need to
  accessed.
 
 I think a possible solution could be an additional optional parameter
 of .getobject used from trusted code when unrestrictedTraverse want to
 be used.  What do you think  ?

Optional arguments will still allow untrusted code to bypass security
checks.

Here are three solutions to this, two of which do not involve catalog
changes:

- Use a proxy role on the script that invokes getObject which grants the
permissions needed.

- Use self.unrestrictedTraverse(brain.getPath()) from trusted code

- Add a private method: unrestrictedGetObject() to the catalog brain API
which does no security checking, but is inaccessible to untrusted code.

I think the last one is a good idea and I will implement it. The other
two are available options for now. 

The problem is that if the existing getObject offers a mode to do no
checking, it is conceivable for untrusted code to arrange for an object
to be cataloged whos path actually points to an otherwise inaccessible
object (granted a more likely senario is that the object is already
cataloged). It could then find that catalog result, call getObject() and
then pass it to the publisher to render it. This would allows a scripter
to publish any object in Zope, because it effectively gives them a way
to call unrestrictedTraverse.

-Casey

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


[Zope-dev] Re: zope-dev list policies

2004-06-25 Thread Casey Duncan
On Fri, 25 Jun 2004 10:06:21 +0200
Godefroid Chapelle [EMAIL PROTECTED] wrote:

[..]
 I am administring plone-i18n mailing list. Non members cannot post. I 
 always post through gmane and my messages get accepted !

As long as posting from Gmane still works, then I'm fine with
restricting postings to members.

If we decide to go ahead I suggest restricting just one list first to
see if there are issues. IMO zope-dev is a reasonable candidate for a
trial list.

-Casey

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


[Zope-dev] Specific Qs about diffs btw Zope 3 Zope 2.x (2.7, etc)

2004-06-25 Thread Eric Hielscher








Hi,



Im trying to decide which version of Zope would work
best for a project on which Ive been assigned to work. Ive
personally had no contact with Zope before yesterday when I downloaded 2.7.1
and 3.0.0b1 to start playing around a bit.



The project involves a web page where users can upload files
of a specific format (zipped SCORM-conformant e-learning files to be
exact). The system would then rip out all of the meta data and perhaps
the full text of the files in the zip and index them for searching. The
MD is in XML, but wed also perhaps like to support RDF and some others
like RSS. Each file in the system would then be linked to the MD by some
sort of GUID-equivalent. Then the users could search the MD and text and
the system would return a results list, and afterward repackage their content.



Now, Ive been asked to decide which version of Zope
would work better for this. I would think that native XML support (which
I read will be better in 3 but dont understand how yet) would be a huge
plus. Also, the new ObjectHub replacement for the ZCatalog might really
help me. Zopes native authentication services have also been given
a huge overhaul and wed like to leverage those as well.



I was hoping that someone out there with better in-depth
knowledge of Zope would be able to read this list of reqs and be able to tell
me in (semi-)detailed fashion just why 3 or 2.x would be a better decision.



Thanks all for your help,



Eric Hielscher






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


Re: [Zope-dev] Specific Qs about diffs btw Zope 3 Zope 2.x (2.7, etc)

2004-06-25 Thread Paul Winkler
On Fri, Jun 25, 2004 at 09:38:15AM -0500, Eric Hielscher wrote:
 The project involves a web page where users can upload files of a
 specific format (zipped SCORM-conformant e-learning files to be exact).
 The system would then rip out all of the meta data and perhaps the full
 text of the files in the zip and index them for searching.


If searching is important to your project, part of the answer depends on 
when you need to release your project.
AFAIK the current zope X3 release
(http://dev.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZopeX3300b1 )
does not support indexing  searching at all. I have no idea when these
features will be available.

Quoting from ZopeX3/doc/CHANGES.txt:


  - We had an object hub service. The object hub service was responsible
for:

- Managing short ids for objects, useful for indexing

- Keeping track of object locations.  This was important when the
  object hub was created, because it wasn't practical to use direct
  object references. No it is, so hub ids are no-longer useful for
  implementing location-independent object references.

The object hub service is dead.

In the future, there will be a utility for use by indexes, that
maintains short ids for objects. Perhaps this will be an indexing id
service.

The index and catalog machinery depend heavily on a facility for
assigning shot ids to objects, currently the hub.  Rather than trying
to remove this dependency now, and ad it back later when we have an
index-id utility, it makes more sense to just remove the index and
catalog facilities for now.

Later, when we create an index-id utility, we'll port the code, which
will still be in the repository, back.




-- 

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


Re: [Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Dieter Maurer
Casey Duncan wrote at 2004-6-25 09:36 -0400:
On Thu, 24 Jun 2004 19:04:55 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:
 ...
 I think, you should only require access rights to the object itself
 and not to all folders from the root to the object.
 ...
 That ZCatalog identifies objects by physical path is an implementation
 artifact. It should not make it impossible to access an
 object via the catalog that otherwise can be accessed without
 problem.
 
  ...
 For hysterical raisins, REQUEST.traverse() does not behave this way.
 It instead checks only the final object traversed.
 That's a good behaviour...

Except when it isn't ;^) OTOH it is closer to the behavior of getObject
in 2.7.0. Ironically it used to use restrictedTraverse long ago...

Have you gotten the main argument?

  That ZCatalog identifies objects by physical path is an
  implementation artifact. It should not make it impossible
  to access an object via the catalog that otherwise can be accessed
  without problems.

When you implement getObject via restrictedTraverse, then
you let getObject() fail for some objects that *are*
accessible by the current user (because this access need not
to use the complete path from the root).

Do not do that!


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


[Zope-dev] [Warning] Zope/ZEO clients: subprocesses can lead to non-deterministic message loss

2004-06-25 Thread Dieter Maurer
ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]'

Today, I hit a nasty error.

The error affects applications under Unix (and maybe Windows) which

  *  use an asyncore mainloop thread (and maybe other asyncore applications)

 Zope and many ZEO clients belong to this class

and

  *  create subprocesses (via fork and system, popen or friends if
 they use fork internally (they do under Unix but I think not
 under Windows)).

The error can cause non-deterministic loss
of messages (HTTP requests, ZEO server responses, ...) destined
for the parent process.
It also can cause the same output to be send several times over sockets.


The error is explained as follows:

  asyncore maintains a map from file descriptors to handlers.
  The asyncore main loop waits for any file descriptor to
  become active and then calls the corresponding handler.

  When a process forks the complete state, including file descriptors,
  threads and memory state is copied and the new process
  executes in this copied state.
  We now have 2 asyncore threads waiting for the same events.

  File descriptors are shared between parent and child.
  When the child reads from a file descriptor from its parent,
  it steals the corresponding message: the message will
  not reach the parent.

  While file descriptors are shared, memory state is separate.
  Therefore, pending writes can be performed by both
  parent and child -- leading to duplicate writes to the same
  file descriptor.


A workaround it to deactivate asyncore before forking
(or system, popen, ...) and reactivate it afterwards: as exemplified
in the following code:

 from asyncore import socket_map
 saved_socket_map = socket_map.copy()
 socket_map.clear() # deactivate asyncore
 pid = None
 try:
 pid = fork()
 if (pid == 0):
 # child
 # ...
 finally:
 if pid != 0:
 socket_map.update(saved_socket_map) # reactivate asyncore


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


Re: [Zope-dev] Re: CatalogBrains since Zope2.7.1b1

2004-06-25 Thread Casey Duncan
On Fri, 25 Jun 2004 20:26:30 +0200
Dieter Maurer [EMAIL PROTECTED] wrote:

 Casey Duncan wrote at 2004-6-25 09:36 -0400:
 On Thu, 24 Jun 2004 19:04:55 +0200
 Dieter Maurer [EMAIL PROTECTED] wrote:
  ...
  I think, you should only require access rights to the object itself
  and not to all folders from the root to the object.
  ...
  That ZCatalog identifies objects by physical path is an
 implementation artifact. It should not make it impossible to access
 an object via the catalog that otherwise can be accessed without
  problem.
  
   ...
  For hysterical raisins, REQUEST.traverse() does not behave this
 way. It instead checks only the final object traversed.
  That's a good behaviour...
 
 Except when it isn't ;^) OTOH it is closer to the behavior of
 getObject in 2.7.0. Ironically it used to use restrictedTraverse long
 ago...
 
 Have you gotten the main argument?

Yes, I intend to change it to use unrestrictedTraverse and then validate
the returned object.

So there... 8^P

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


[Zope-dev] RE: [ZODB-Dev] [Warning] Zope/ZEO clients: subprocesses can lead tonon-deterministic message loss

2004-06-25 Thread Tim Peters
[Dieter Maurer]
 ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]'

Which I've honored.

 Today, I hit a nasty error.

 The error affects applications under Unix (and maybe Windows) which

   *  use an asyncore mainloop thread (and maybe other asyncore
  applications)

  Zope and many ZEO clients belong to this class

Note a possible complication:  ZEO monkey-patches asyncore, replacing its
loop() function with one of its own.  This is done in ZODB's
ThreadedAsync/LoopCallback.py.

 and

   *  create subprocesses (via fork and system, popen or friends if
  they use fork internally (they do under Unix but I think not
  under Windows)).

It may be an issue under Cygwin, but not under native Windows, which
supports no way to clone a process; file descriptors may get inherited by
child processes on Windows, but no code runs by magic.

 The error can cause non-deterministic loss of messages (HTTP requests,
 ZEO server responses, ...) destined for the parent process. It also can
 cause the same output to be send several times over sockets.

 The error is explained as follows:

   asyncore maintains a map from file descriptors to handlers.
   The asyncore main loop waits for any file descriptor to
   become active and then calls the corresponding handler.

There's a key related point, though:  asyncore.loop() terminates if it sees
that the map has become empty.  This appears to have consequences for the
correctness of workarounds.  For example, this is Python's current asyncore
loop (the monkey-patched one ZEO installs is similar in this respect):

def loop(timeout=30.0, use_poll=False, map=None):
if map is None:
map = socket_map

if use_poll and hasattr(select, 'poll'):
poll_fun = poll2
else:
poll_fun = poll

while map:
poll_fun(timeout, map)

If map becomes empty, loop() exits.


   When a process forks the complete state, including file descriptors,
   threads and memory state is copied and the new process
   executes in this copied state.
   We now have 2 asyncore threads waiting for the same events.

Sam Rushing created asyncore as an alternative to threaded approaches;
mixing asyncore with threads is a nightmare; throwing forks into the pot too
is a good working definition of hell wink.

   File descriptors are shared between parent and child.
   When the child reads from a file descriptor from its parent,
   it steals the corresponding message: the message will
   not reach the parent.

   While file descriptors are shared, memory state is separate.
   Therefore, pending writes can be performed by both
   parent and child -- leading to duplicate writes to the same
   file descriptor.


 A workaround it to deactivate asyncore before forking (or system,
 popen, ...) and reactivate it afterwards: as exemplified in the
 following code:

  from asyncore import socket_map
  saved_socket_map = socket_map.copy()
  socket_map.clear() # deactivate asyncore

As noted above, this may (or may not) cause asyncore.loop() to plain stop,
in parent and/or in child process.  If there aren't multiple threads, it's
safe, but presumably you have multiple threads in mind, in which case
behavior seems unpredictable (will the parent process's thread running
asyncore.loop() notice that the map has become empty before the code below
populates the map again?  asyncore.loop() will or won't stop in the parent
depending on that timing accident).

  pid = None
  try:
  pid = fork()
if (pid == 0):
# child
# ...
  finally:
  if pid != 0:
socket_map.update(saved_socket_map) # reactivate asyncore

Another approach I've seen is to skip mucking with socket_map directly, and
call asyncore.close_all() first thing in the child process.  Of course
that's vulnerable to vagaries of thread scheduling too, if asyncore is
running in a thread other than the one doing the fork() call.

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


[Zope-dev] Re: [ZODB-Dev] [Warning] Zope/ZEO clients: subprocesses can lead to non-deterministic message loss

2004-06-25 Thread Paul Winkler
On Fri, Jun 25, 2004 at 07:23:19PM +0200, Dieter Maurer wrote:
 ATTENTION: Crosspost -- Reply-To set to '[EMAIL PROTECTED]'
 
 Today, I hit a nasty error.
 
 The error affects applications under Unix (and maybe Windows) which
 
   *  use an asyncore mainloop thread (and maybe other asyncore applications)
 
  Zope and many ZEO clients belong to this class
 
 and
 
   *  create subprocesses (via fork and system, popen or friends if
  they use fork internally (they do under Unix but I think not
  under Windows)).

Hm.  this applies to external methods and product code that makes
these calls?
 
-- 

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