Re: [Zope-dev] Cache-bug in handling of files
So there is nothing else I can do but to make my files open in a new window then... But what I dont understand is why IE doesnt send any If-Modified-Since header? Shouldnt it always do that if the settings are not set to never update cached files? Peter Jim Sanford skrev: since all the data at my corporate intranet site is pulled from a RDMS, all my refrence URLS are generated in JavaScript and have a rnd="a randomly generated number between 1 and a million" to force the browser to get the current page. __ Jim Sanford . Database Engineer / \ / Accelerated Technology, Inc. / / 720 Oak Circle Drive East / / \Mobile, AL 36609 / / \ Voice: 334-661-5770 fax: 334-661-5788 / \ E-Mail: [EMAIL PROTECTED] Web: http://www.atinucleus.com Nucleus. All You NEED in an RTOS. Royalty Free __ - Original Message - From: Brian Lloyd [EMAIL PROTECTED] To: 'Peter Arvidsson' [EMAIL PROTECTED]; Brian Lloyd [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, August 11, 2000 10:44 AM Subject: RE: [Zope-dev] Cache-bug in handling of files I am using IE 5 (5.00.2919.6307), cache settings set to: "Check for newer versions of stored pages: Automatically Those settings should get the new file if it has changed. I am accessing the server through a proxy.. could that be a problem? I think it would be strange if everyone accessing the website I am building can see the new files.. What do you think? Peter Peter - I have done some testing here and I can demonstrate that this is an IE issue. I set my cache to "Automatically" like yours and restarted it. I then opened a Netscape and created a new file object. I instrumented the code in the 'index_html' method of File objects so that I could tell _for sure_ whether things were actually being called at the server or not. Here's what I did: - create a file 'myfile.txt', uploading a contents of text1.txt into it. - visit the view tab with IE. The server confirms that the index_html was called, and the whole content was sent, not a 304. - now (using netscape again) upload the contents of text2.txt into the file object. The mgmt screen correctly shows the updated byte length, etc. - click the 'view' tab again on IE. My instrumenting confirms that IE is not contacting the server *at all* no matter how many times I click the 'view' tab, and I keep seeing the old content. A look at the headers produced by this shows nothing that tells IE it should be doing that: HTTP/1.1 200 OK Server: Zope/(unreleased version) ZServer/1.1b1 Date: Fri, 11 Aug 2000 15:18:50 GMT Connection: close Content-Type: text/plain Content-Length: 944 Last-Modified: Fri, 11 Aug 2000 15:16:06 GMT Interestingly, if you open the "view" tab in a new window, you'll see the updated content. Now, using that same new window, set your cursor at the end of the url string in the url bar and hit return. IE seems to reload the page, but it is not actually even contacting the server. Stranger yet, if you click the "refresh" button it *will* contact the server (and it passes an If-Modified-Since header, and correctly gets a 304 Not Modified). Now, use netscape to change the content again. The whole thing starts over. Clicking the 'view' link on the page or pressing return in the URL bar will not even contact the server and the only way to get the updated content is to explicitly press "refresh" or open a new window, even though the resource returned no caching information one way or the other. I'm going to close that bug report and include this report for those who may find it useful in the future. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.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 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 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
Re: [Zope-dev] Cache-bug in handling of files
On Mon, 14 Aug 2000 10:01:03 +0200, Peter Arvidsson [EMAIL PROTECTED] wrote: So there is nothing else I can do but to make my files open in a new window then... But what I dont understand is why IE doesnt send any If-Modified-Since header? Shouldnt it always do that if the settings are not set to never update cached files? Browser dont spontaneously generate If-Modified-Since - only if you include a Last-Modified header in the original response (Im not entirely sure whether or not they are allowed to) Note that Brian was observing that IE was not sending any request to the server - any request (even one that includes cache control headers) is going to involve a performance hit. Brian: could you repeat your test including the header cache-control: must-revalidate This certainly *should* have the desired effect of not letting IE display stale data. Ive covered the use of this header in some detail in a recent HowTo: http://www.zope.org/Members/htrd/howto/caching 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] ZPatterns, Transactions, _register/_unregister
Hi,
I've encountered some weird behaviour in the ZPatterns Transactional class when
I was trying to write a User Source for the Login Manager Product.
I'm using Zope 2.2.0 with LoginManager 0.8.7a1 and ZPatterns 0.4.1snap1
The problem is that _unregister seems to be trying to delete the _v_registered
attribute of an object that doesn't have it set whenever I return None from
authenticateUser(). The weird thing is that the object seems to be
_register()ed and _v_registered appears to be set to 1 in _register(), but when
_unregister() is called it has the value 'None' again.
I've attached my code that's trying to implement the UserSource.
here is what my modified _register and _unregister functions look like:
def _register(self):
f=open('/tmp/zopelog', 'a', 0)
f.write('Register %s(%s)\n' % (self.id, str(self)))
f.write('Before: %s._v_registered=%s\n' % (self.id, getattr(self,
'_v_registered', 'N/A')))
for i in traceback.format_stack():
f.write(i)
if self._v_registered: return
get_transaction().register(Reporter(self))
self._v_registered = 1
f.write('After: %s._v_registered=%s\n' % (self.id, getattr(self,
'_v_registered', 'N/A')))
f.close()
def _unregister(self):
f=open('/tmp/zopelog', 'a', 0)
f.write('Unregister %s(%s)\nBefore: %s._v_registered=%s\n' \
% (self.id, str(self), self.id, getattr(self, '_v_registered', 'N/A')))
f.close()
del self._v_registered
and this is a sample log:
Register UserSource(NisUserSource instance at 85ab2e8)
Before: UserSource._v_registered=None
File "/home/picard/bpe/Zope-2.2.0-src/ZServer/PubCore/ZServerPublisher.py", line 95,
in __init__
response=response)
File "/home/picard/bpe/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py", line 222,
in publish_module
response = publish(request, module_name, after_list, debug=debug)
File "/home/picard/bpe/Zope-2.2.0-src/lib/python/ZPublisher/Publish.py", line 162,
in publish
object=request.traverse(path, validated_hook=validated_hook)
File "/home/picard/bpe/Zope-2.2.0-src/lib/python/ZPublisher/BaseRequest.py", line
427, in traverse
else: user=v(request, auth, roles)
File
"/home/picard/bpe/Zope-2.2.0-src/lib/python/Products/LoginManager/LoginManager.py",
line 110, in validate
user = _DefaultAuth.findLogin(self, request, auth, user, roles)
File
"/home/picard/bpe/Zope-2.2.0-src/lib/python/Products/LoginManager/LoginMethods.py",
line 147, in findLogin
user = manager.getItem(name)
File
"/home/picard/bpe/Zope-2.2.0-src/lib/python/Products/LoginManager/LoginManager.py",
line 65, in getItem
user = source.__of__(self).getItem(name)
File "/home/picard/bpe/Zope-2.2.0-src/lib/python/Products/ZPatterns/Rack.py", line
61, in getItem
self._registerCanonical(k,item) # XXX Should we cache non-existence?
File
"/home/picard/bpe/Zope-2.2.0-src/lib/python/Products/ZPatterns/DataManagers.py", line
52, in _registerCanonical
self._register()
File
"/home/picard/bpe/Zope-2.2.0-src/lib/python/Products/ZPatterns/Transactions.py", line
47, in _register
for i in traceback.format_stack():
After: UserSource._v_registered=1
Unregister UserSource(NisUserSource instance at 85ab2e8)
Before: UserSource._v_registered=None
from Products.ZPatterns.PlugIns import PlugIn
from Products.LoginManager.UserSources import BasicUserSource,LoginUser
from Products.LoginManager.LoginMethods import LoginMethod
from Products.LoginManager import LoginManager
import nis, string, crypt
from Products.ZPatterns.PlugIns import defaultConstructors
class NisUserSource(BasicUserSource, PlugIn):
__plugin_kind__ = "User Source"
meta_type = "NIS User Source"
f=open('/tmp/zopelog', 'a', 0)
i=0
def dbg(self, str):
self.f.write('[%03d] %s\n' % (self.i, str))
self.i = self.i + 1
def retrieveItem(self, name):
self.dbg('retrieveItem: %s' % name)
try: passwd=nis.match(name, 'passwd.byname')
except nis.error: return None
user=LoginUser(name)
user._setRack(self)
self.dbg('retrieveItem: %s ok.' % user.getUserName())
return user
def authenticateUser(self, user, password, REQUEST=None):
self.dbg('authenticateUser: %s %s' % (user, 'password'))
name=user.getUserName()
if name is None: return None
try: passwd=nis.match(name, 'passwd.byname')
except nis.error: return None
crypted=string.split(passwd, ':')[1]
test=crypt.crypt(password, crypted)
self.dbg('%s == %s: %d' % (crypted, test, crypted==test))
return crypted==test
def rolesForUser(self, user):
if user.getUserName() == 'bpe':
return ['Write Access']
else:
return ['Read Access']
def domainsForUser(self, user):
return []
def initialize(context):
context.registerPlugInClass(
Re: [Zope-dev] Acquisition Confusion :S
Steve Alexander wrote: That makes for a lot of security checks. There are possible optimisations, though. But this starts to get even more complicated. Does that mean it won't work, would be very slow, or both? ;-) cheers for looking 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 )
Re: [Zope-dev] Acquisition Confusion :S
Michel Pelletier wrote: A.B.C.D Look for D in C, if it's not there, look in B if it's not there, look in A Someone correct me if I'm wrong here, but... This is a linear search, which is the way acquisition *used* to work. Which Zope version? ;-) Consider: A / B/ C/ D (A contains B, B contains C and D). A.B.C.D By your desire first look for D in C, then B and then A. Yup... But A says "You cannot see Ds". Now, in the linear case, D is found in B, and A is never asked if this operation is permitted. This is a security violation because root policies should be enforced unless they are explicitly overidden further down. Hurm :S I didn't say I had the answers, I was just posing the question ;-) Further, it actually makes *more* sense because the Well, maybe for security, but not for everyday use by people who have trouble getting their heads around (((D o C) o (C o A)) o ((C o A) o (B o A))) and the like... Not from the perspective of the way most development is done. For example, when you want to have your children objects (whatever they may be) be acquireable, you don't need to think about the complexity of the situation, you just make sure you make them accessable in the context *of* you. Hmmm, the thing which is bugging me is described quite nicely here: http://www.zope.org/Wikis/zope-dev/AcquisitionFeedback How can Steve achieve what he wants with the way acquisition currently works? 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] Acquisition Confusion :S
Chris Withers wrote: Steve Alexander wrote: That makes for a lot of security checks. There are possible optimisations, though. But this starts to get even more complicated. Does that mean it won't work, would be very slow, or both? ;-) It will work. It will be slower. I think Evan Simpson's suggestion of adding two new methods to the acquisition wrapper is a good idea. That way, Zope remains backward-compatible, and you get to make an explicit choice of how you want acquisition to work, if you wish. Perhaps there's a Collector entry on this? quoted from Evan's email. Untested. def aq_context(ob): context = [] while ob is not None: context.append(ob.aq_base) ob = ob.aq_parent ob = context.pop() while context: ob = context.pop().__of__(ob) return ob def aq_containment(ob): context = [] while ob is not None: context.append(ob.aq_base) ob = ob.aq_inner.aq_parent ob = context.pop() while context: ob = context.pop().__of__(ob) return ob As he pointed out, they'd make useful external methods too. Perhaps these will find their way into Zope 2.3? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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] hmmm.. wierd permission issues with getPersistentItemIDs()...
Hi ZPatterns folks... ZPatterns-0.4.1snap1 Zope2.2.0-src I have a specialist with a defaultRack storing DataSkin subclassed ZClass instances with only persistent attribute providers. dtml-var "defaultRack.getPersistentItemIDs()" or dtml-in "defaultRack.getPersistentItemIDs()" ... /dtml-in raise AuthorizationFailed dtml-in "defaultRack.getPersistentItemIDs()" sort ... /dtml-in works fine. What did I do now? ;-) thanks for any ideas! -steve ___ 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] Acquisition Confusion :S
Evan Simpson wrote: I haven't got the whole reason, but here are some of the pieces: - never expose a "bare" object, or even one with an incomplete context Why? You can get at it through aq_base anyway, surely? Also, Jim Fulton wrote a while back: Sure. There is no guarentee that all objects are wrapped. - allow the user to backtrack along the context chain I take it this is the reason for wrappers? Would it matter if the wrappers were structured differently to provide a different search order? These two together give you the part about aq_parent always being the previous acquisition result. Yup, got that :-) - allow recovery of containment information Urm, didn't quite follow that :S - base security on containment aq_inner, right? These two motivate the simplification of raw acquisition. Which simplification is that? The current acquisition implementation is thus a weird hybrid of containment and context. I'll say ;-) It isn't hard to convert a standard acquisition wrapper into either of the other sort. I'm going to propose adding something like the following functions: def aq_context(ob): def aq_containment(ob): Okay, so taking our long-running example: A / I B/ I C/ D (A contains B and C, C contains D). (A contains an I, as does B) A.B.C.D Which I, if any, would each of the following return: dtml-var expr="aq_context(A.B.C.D).I" dtml-var expr="aq_context(A.B.C).I" dtml-var expr="aq_context(A.B).I" dtml-var expr="aq_context(A).I" dtml-var expr="aq_containment(A.B.C.D).I" dtml-var expr="aq_containment(A.B.C).I" dtml-var expr="aq_containment(A.B).I" dtml-var expr="aq_containment(A).I" 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] ZCatalog brains
Steve Alexander wrote: Although there are ways to do this now, I guess I was wondering about making it a standard part of catalogs. I'm sure code will be greatfully recieved ;-) Thinking further though, if it is as easy as adding "url" to the catalog's metadata, why bother? Hmm, how about (for Zope 2.2 anyway) just adding a metadata column called getPhysicalPath? As long as your catalogued items support the traversal interface, this should work fine :-) 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] hmmm.. wierd permission issues with getPersistentItemIDs()...
Steve Spicklemire wrote: Hi ZPatterns folks... ZPatterns-0.4.1snap1 Zope2.2.0-src I have a specialist with a defaultRack storing DataSkin subclassed ZClass instances with only persistent attribute providers. dtml-var "defaultRack.getPersistentItemIDs()" When I call that, I get BTreeItems object at 869a5d8. To get that list of IDs, I use an external method: def get_persistent_ids(self): try: items = self.defaultRack.aq_base.getPersistentItemIDs() return map(lambda x: x, items) except: import sys, traceback, string etype, val, tb = sys.exc_info() sys.stderr.write(string.join(traceback.format_exception(etype, val, tb),'')) del etype, val, tb I've tried something like your code, with no sheetproviders in the rack. I can't reproduce your error. I'm using the method as a Manager. or dtml-in "defaultRack.getPersistentItemIDs()" ... /dtml-in raise AuthorizationFailed dtml-in "defaultRack.getPersistentItemIDs()" sort ... /dtml-in works fine. What did I do now? ;-) Line 318, Rack.py. The method getPersistentItemIDs has no docstring. Is that still significant under the new security model? Does the user you're running the method as have the permission "Access contents information" ? Looks like you may have uncovered a Zope security bug in dtml-in ... sort :-/ How could we test this further? -- Steve Alexander Software Engineer Cat-Box limited http://www.cat-box.net ___ 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 security alert and hotfix product...
The issue involves the fact that the getRoles method of
user objects
contained in the default UserFolder implementation returns
a mutable
Python type. Because the mutable object is still
associated with the
persistent User object, users with the ability to edit DTML could
arrange to give themselves extra roles for the duration of
a single
request by mutating the roles list as a part of the request
processing.
OK, so I can exploit this with something similar to
user.getRoles().append('A Role That I Dont Have')
But, why isnt the append method covered by the new
inaccessible-by-default 2.2 security rules?
Back when we were considering how much tightening would
be considered acceptable in one dose, we ended up not
preventing access to methods of mutable python types
([], {}). The main reason that we were aware of a fair
number of people using this (including one or two internal
things) for legitimate things:
dtml-var "REQUEST.set('some_stuff', [])"
dtml-in other_stuff
dtml-call "some_stuff.append(_['sequence-item'])"
/dtml-in
etc. So we made the decision not to break those things.
The real problem, of course, is that the Zope APIs (and
the APIs of add on products) should not return references
to mutable subobjects. If an API method must return a
mutable Python type, it should return a copy rather than
a direct reference:
def myMethod(self):
# self.stuff is a dict
# dont do this!
return self.stuff
# do this instead
return self.stuff.copy()
# or if stuff is a list either do:
return self.stuff[:]
# or
return tuple(self.stuff)
Now - should methods of mutable types be off-limits in the
future? I'm not sure that the jury is in yet on that. Consider
that PythonMethods (that soon will be part of the core) play
by basically the same rules as dtml. While it might be pretty
easy to argue that the list-juggling in my DTML example above
is bad practice, I think most people would expect to be able
to do:
mylist=[]
mylist.append('one')
return mylist
...in a PythonMethod and have it work. I don't think it would
be acceptable for 'append' to be off-limits in this case, so
the alternative is that the security machinery would somehow
have to be able to distinguish mutables created by the user
from those obtained from the secure environment. That would
probably mean that API code would have to make some sort of
security assertions about mutables they returned. Exactly
how that would work I don't know...
Brian Lloyd[EMAIL PROTECTED]
Software Engineer 540.371.6909
Digital Creations http://www.digicool.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] Acquisition Confusion :S
From: Chris Withers [EMAIL PROTECTED] - never expose a "bare" object, or even one with an incomplete context Why? You can get at it through aq_base anyway, surely? Only from unrestricted code. DTML and (CVS) Python Methods only let you access aq_parent. This only applies to objects that are part of the containment hierachy, of course. Brand new objects aren't wrapped, nor are simple non-persistent types like lists and dicts. - allow the user to backtrack along the context chain I take it this is the reason for wrappers? Would it matter if the wrappers were structured differently to provide a different search order? Only to anyone who depends on the current behavior :-) Also, there is a very limited range of "natural" ways to construct the wrappers. Once contructed, of course, we can fool with them in arbitrary ways. - allow recovery of containment information Urm, didn't quite follow that :S We want to be able to find out what an object's container is, regardless of what we acquired it from. In raw acquisition, there's no straightforward way to do this. In simplified acquisition, aq_inner.aq_parent is the container. The simplification is the rule (A o B) o (B o C) = A o (B o C). Okay, so taking our long-running example: A / I B/ I C/ D (A contains B and C, C contains D). (A contains an I, as does B) A.B.C.D Which I, if any, would each of the following return: All of these would search the dotted expression from right to left, so they would give you B's I. dtml-var expr="aq_context(A.B.C.D).I" dtml-var expr="aq_context(A.B.C).I" dtml-var expr="aq_context(A.B).I" All of these would search the containers of the right-most object, so the first two would give you A's I, and the third B's I. dtml-var expr="aq_containment(A.B.C.D).I" dtml-var expr="aq_containment(A.B.C).I" dtml-var expr="aq_containment(A.B).I" Cheers, Evan @ digicool 4-am ___ 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: Zope security alert and hotfix product...
Now - should methods of mutable types be off-limits in the future? [...] I don't think it would be acceptable for 'append' to be off-limits in this case, so the alternative is that the security machinery would somehow have to be able to distinguish mutables created by the user from those obtained from the secure environment. That would probably mean that API code would have to make some sort of security assertions about mutables they returned. I have another alternative -- Unless I really intend to return an unprotected mutable across subsystems, most often it's a mistake. Even if security isn't an issue, it leads to wonderfully obscure bugs if a customer of my class blithely modifies my return value. (I returned it to you, after all, you thought it was yours now!) If I do want to return a dictionary for you to *read*, I could just as easily code my intention and return a read-only class that implements __getitem__. Since on occasion I might deliberately want to return an unprotected mutable value for a good reason, what would be helpful is if the security system forbid me from returning unprotected mutable values unless I explicitly say I intend to do so. I'd encourage the check to recursively descend through tuples and, if we create a standard read-only dictionary for everyone to use, through read-only dictionaries. Note such a check would be just as helpful for products written using Python Methods, or DTML, as it would be for products written in plain Python. Then the security system doesn't need to keep track of where unprotected mutables came from. Once I've said explicitly that I intend to return an unprotected mutable, I can take care to return a copy that I don't use after I've passed it on to you. Andrew ___ 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] zope221b1 - zclass zexp import into clean database error
Shane has tracked this down to a mis-bugfix in the beta - the fix will be in the 2.2.1 final. Brian Lloyd[EMAIL PROTECTED] Software Engineer 540.371.6909 Digital Creations http://www.digicool.com -Original Message- From: Dr. Ross Lazarus [mailto:[EMAIL PROTECTED]] Sent: Saturday, August 12, 2000 9:49 PM To: [EMAIL PROTECTED] Cc: Brian Lloyd Subject: [Zope-dev] zope221b1 - zclass zexp import into clean database error More on testing zope221b1 - source tar, redhat 6.2 I seem to be the only one reporting problems on the list (0-:) - it really is just me. Thought I better try again - start with a clean slate So, I restarted zope with a new empty Data.fs from the 221b1 source distribution. Started as superuser, made a real user with manager/owner rights. Logged in as the real user, took ownership of the entire heirarchy. Tried to import a zclass zexp file freshly exported from 2.2.0 that I've been happily using with 2.2.0 and previously. Traceback appears below === Zope Error Zope has encountered an error while publishing this resource. Error Type: Permission mapping error Error Value: Attempted to map a permission to a permission, Add SMP Blocks, that is not valid. This should never happen. (Waaa). -- -- Troubleshooting Suggestions The URL may be incorrect. The parameters passed to this resource may be incorrect. A resource that this resource relies on may be encountering an error. For more detailed information about the error, please refer to the HTML source for this page. If the error persists please contact the site maintainer. Thank you for your patience. Traceback (innermost last): File /usr/local/home/rossl/zope221b1/lib/python/ZPublisher/Publish.py, line 222, in publish_module File /usr/local/home/rossl/zope221b1/lib/python/ZPublisher/Publish.py, line 187, in publish File /usr/local/home/rossl/zope221b1/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: Traversable) File /usr/local/home/rossl/zope221b1/lib/python/ZPublisher/Publish.py, line 171, in publish File /usr/local/home/rossl/zope221b1/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: manage_importObject) File /usr/local/home/rossl/zope221b1/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: manage_importObject) File /usr/local/home/rossl/zope221b1/lib/python/OFS/ObjectManager.py, line 508, in manage_importObject (Object: Traversable) File /usr/local/home/rossl/zope221b1/lib/python/OFS/ObjectManager.py, line 263, in _setObject (Object: Traversable) File /usr/local/home/rossl/zope221b1/lib/python/OFS/ObjectManager.py, line 271, in manage_afterAdd (Object: Traversable) File /usr/local/home/rossl/zope221b1/lib/python/ZClasses/ZClass.py, line 422, in manage_afterAdd (Object: ZBlockStore) File /usr/local/home/rossl/zope221b1/lib/python/OFS/ObjectManager.py, line 271, in manage_afterAdd (Object: Traversable) File /usr/local/home/rossl/zope221b1/lib/python/App/Factory.py, line 144, in manage_afterAdd (Object: RoleManager) File /usr/local/home/rossl/zope221b1/lib/python/AccessControl/Permi ssionMapping.py, line 137, in manage_setPermissionMapping (Object: RoleManager) (Info: (['', 'Access contents information', 'Add Database Methods', 'Add Documents, Files, and Images', 'Add Documents, Images, and Files', 'Add External Methods', 'Add Folders', 'Add LDAPAdapter Object', 'Add MailHost objects', 'Add Survey Creator', 'Add Sybase Database Connections', 'Add TinyTable', 'Add User Folders', 'Add Versions', 'Add Vocabularies', 'Add Z Gadfly Database Connections', 'Add ZCatalogs', 'Add ZWiki Pages', 'Add Zope Tutorials', 'Browse LDAPAdapter', 'Change DTML Documents', 'Change DTML Methods', 'Change Database Connections', 'Change Database Methods', 'Change External Methods', 'Change Images and Files', 'Change LDAPAdapter', 'Change TinyTable', 'Change Versions', 'Change ZWiki Pages', 'Change configuration', 'Change permissions', 'Change proxy roles', 'Change survey', 'Create class instances', 'Create survey', 'Delete objects', 'Edit Factories', 'FTP access', 'Import/Export objects', 'Join/leave Versions', 'Manage Vocabulary', 'Manage Z Classes', 'Manage ZCatalog Entries', 'Manage properties', 'Manage users', 'Open/Close Database Connection', 'Open/Close Database Connections', 'Query TinyTable Data', 'Query Vocabulary', 'Save/discard Version changes', 'Search ZCatalog', 'Submit survey', 'Take ownership', 'Test Database Connections', 'Undo changes', 'Use Database Methods', 'Use Factories', 'Use mailhost services', 'View', 'View History', 'View management screens'], 'Add SMP Blocks', 0)) Permission
