August 2000 - Zope-Dev

Fighting with ZServer
by Dieter Maurer 21 Aug '00

21 Aug '00

Since this afternoon, I am fighting with ZServer. Currently, it seems Zserver is winning .... I do not understand, what I see... At work: Zope 2.1.6, Sparc Solaris 2.7, Linux Netscape 4.51 Sometimes, images are not shown by Netscape (broken image). No "simple" reload is able to change this, however a "forced" reload lets Netscape show the image correctly. From then on, the image is always shown correctly: by "simple" reload, "forced" reload or directly (served from cache). The strange thing, inside "Image.index_html" the failing "simple" reload and the succeeding "forced" reload look completely identical. At home: Zope 2.1.6, Intel Linux 2, Linux Netscape 4.5 All images are always shown correctly. However, there is no log entry in "var/Z2.log" for about 50 % of the requests that are answered by a 304 response. It is non-deterministic whether a log entry is written or not. Did you ever see something like this? Dieter

1 0

RE: [Zope-dev] Re: __ac_permissions__ question
by Brian Lloyd 21 Aug '00

21 Aug '00

> > Assertions made on a method in a subclass override the > assertions made > > in the base class. > > Okay, Posting has the following list of methods for the 'view' > permission: > ['date_posted','body_len','date_created','time_created','attac > hment','thread_path','index_html','showBody', > > 'desc_items','dupString','striptags','tpId','tpURL','this','ha > s_items','thread','title','author','body', > 'email','subject'] > > Now, what I want to do is add the following methods to this > list for the > Article class which subclasses Posting: > ['prev_item','next_item','showSummary','desc_items'] > > How do I do that? class Article(Posting): __ac_permissions__ = ( ('View', ('prev_item','next_item','showSummary','desc_items'), ('Anonymous', 'Manager')), ) It may be helpful to think of it this way: - the class that defines an attribute/method is responsible for protecting it (declaring it in a permission or with other security assertions) - a class doesn't have to worry about assertions made by its base classes (the base classes will have worried about the attrs they defined) - any class that defines security info must be initialized with default__class_init__ for the right thing to happen. Note that the only time you really have to care about what your base classes did is if you need to redefine the permission used cover an inherited attribute. For ex: class Posting: # doAction_A is under view permission __ac_permissions__ = ( ('View', ('doAction_A',), ('Anonymous', 'Manager')), ) def doAction_A(self): ... class Article(Posting): # For Articles, I want doAction_A to be under the 'Spam' # permission. __ac_permissions__ = ( ('View', ('doAction_B',), ('Anonymous', 'Manager')), ('Spam', ('doAction_A',), ('Anonymous', 'Manager')), ) Hope this helps! Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

__ac_permissions__ question
by Chris Withers 21 Aug '00

21 Aug '00

If I define the following in an Article class (which subclasses Posting): __ac_permissions__ = Posting.__ac_permissions__ + ( ('View', ['prev_item','next_item','showSummary','desc_items'], ('Anonymous', 'Manager')), ) and Posting.__ac_permissions__ also defines a 'View' permission, which methods are covered? (the ones from Posting, the ones from Article or (hopefully) the union of the two sets of methods) cheers, Chris PS: If it's nto the union, how can I achieve this effect?

2 5

RE: [Zope-dev] attribute protection question
by Brian Lloyd 21 Aug '00

21 Aug '00

> Hmmm. Hence the problem with properties that meant OFS.Item.SimpleItem > had to have __allow_access_to_unprotected_subobjects__=1? > > Can you not just assign roles to properties as they're created or am I > missing something else? That's one way to do it - but it will require some thought to make sure we do it right. Having the "=1" assertion is a short-term solution intended to avoid breaking everyone's code for 2.2 while taking a step on the road to changing the default policy. I expect that it will soon make a distinction between properties and attributes that are not properties, which will be the next step on the road. I'd like to see this for 2.3, but I don't promise specific features for particular release numbers anymore :) I do want it to be Soon. My hope is that we'll release a 2.x beta where: o far less things are available via the __allow_... hack o product authors and app builders will have auth problems because they're using attrs formerly covered by the hack o the new security assertion spelling from dev.zope.org will be available and make it much easier for people to go in and protect the problem attrs correctly :) o most if not all of the Zope core will be using the new assertion style, which will help the product authors along with the "guide" to making security assertions that will be a deliverable of that dev.zope.org project o we'll be one more step closer to where we want to be Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

1 0

intSet and the new security model
by Chris Withers 21 Aug '00

21 Aug '00

Hi, Squishdot uses an intSet called 'thread' to store some information. Items in this intSet are used in several DTML methods, for example: <A HREF="<dtml-var site_url >/<dtml-var expr="thread[0]" >/index_html#<dtml-var id >">Return to main thread</A> Now, in Zope 2.2 this throws an unauthorized error as show in the PS. How can I make this go away in a non-hacky fashion? cheers, Chris PS:

1 2

RE: [Zope-dev] attribute protection question
by Brian Lloyd 21 Aug '00

21 Aug '00

> In the new security model is it just attributes that are methods that > are protected or is it all attributes? All attributes - methods just happen to be the most common case. > Now, would I need body__roles__=None or somethign similar to > be able to > do: > <dtml-var body> Yes, or (better) associate the name of the attribute with a permission. Brian Lloyd brian(a)digicool.com Software Engineer 540.371.6909 Digital Creations http://www.digicool.com

2 1

Squish
by Chris Withers 21 Aug '00

21 Aug '00

...it was named appropriately ;-) Right, this would probably be easier if you have a background knowledge of Confera/Squishdot code, anyway... there's two classes, SquishSite and Posting. They don't inherit from each other, but postings are always contained in a SquishSite and eveything is Acquisition.Implicit-inheriting. Right, there's a whole host of methods: def postingValues(self): def tpId(self): def tpURL(self): def this(self): return self def has_items(self): def desc_items(self): ...that are implemented identically. So I thought 'why?' Why can't they just be implemented in the SquishSite class and acquired by the postings? So I commented them out... bad move :( Things that used desc_items, and a dtml-tree that used postingValues suddenly started producing infinite recusion errors and other weirdness. I think, instead of returning the children like postingValues is supposed to, it just returned the children of the Site object instead. very strange. Can you help explain? (it seemed to me like the method was being acquired alright, but the 'self' being used was that of the object the method was acquired from rather than object the method was being called on) The code for the two methods of any substance (the rest are just things like 'return self' and 'return self.id') is shown below. cheers, Chris # protected by 'View' permission def desc_items(self): # """ return latest list of replies """ mlist = [] mstack = Stack() if self.has_items(): plist = [] for id in self.ids: plist.append(id) plist.reverse() for id in plist: mstack.push(id) while not mstack.isEmpty(): item_id = mstack.pop() item = self.data[item_id] mlist.append(item) if item.has_items(): plist = [] for id in item.ids: plist.append(id) plist.reverse() for id in plist: mstack.push(id) return map((lambda x, p=self: x.__of__(p)), mlist) # protected by 'Manage Postings' permission def postingValues(self): # """ return all replies """ return map(lambda x, p=self: x.__of__(p), self.data.map(self.ids)) self.data is an IOBtree in the SquishSite object. self.ids is an intSet in the SquishSite object. (I think both are acquired by Posting objects)

1 0

Unauthorized head hurting :(
by Chris Withers 21 Aug '00

21 Aug '00

Is there any way you can find out what, exactly (ie a traceback ;-) is causing an unauthorized error? cheers, Chris

1 0

Methods with no __roles__ defined no always protected?
by Chris Withers 21 Aug '00

21 Aug '00

Hi, Just doing Squishdot for 2.2 when I noticed the following: The SquishSite class has a method called item_count() which is used on one of the management pages. It currently isn't protected by any permissions or __roles__ and yet it still works fine on the management screen concerned. I thought this sort of thing was supposed to throw up an unauthorized error in 2.2? cheers, Chris PS: It is now protected by a permission, but I can send anyone who cares a version which isn't...

2 2

attribute protection question
by Chris Withers 21 Aug '00

21 Aug '00

In the new security model is it just attributes that are methods that are protected or is it all attributes? For example, I have a lump of text in an Article class which is stored in self.body. Now, would I need body__roles__=None or somethign similar to be able to do: <dtml-var body> ? cheers, Chris

1 0