Milos Prudek wrote:

Error Type: Unauthorized Error Value: The container has no security assertions. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Here's your key bit, what is the container and why doesn't it have any securiyt assertions?

It look like browser_id_manager will not allow me to question whether it is folderish. This looks silly. What permission should I check to find out which objects refuse to divulge this info?

Huh? just do a try/except and only catch unauthorised errors... Chris

Milos Prudek wrote:

...

Here's your key bit, what is the container and why doesn't it have any securiyt assertions?

Forgive a silly question, but what is a security assertion?

http://www.zope.org/Documentation/Books/ZDG/current/Security.stx Chris

Shane, any ideas? Chris Paul Winkler wrote:

On Fri, Sep 12, 2003 at 02:09:08PM +0100, Chris Withers wrote:

...

Milos Prudek wrote:

...

Error Type: Unauthorized Error Value: The container has no security assertions.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

FWIW, I recently started getting this exception on some of my own code that had been working - and has NOT been changed. It started when I upgraded from 2.6.2b3 to 2.6.2b5. BUt that can't have been the culprit because weirdly, another InstanceHome running off the same SoftwareHome did NOT experience the errors. I made sure that the affected Product code was identical in the two instances - I copied it back from the working one to the non-working one. No change.

I eventually realized that the error-stricken InstanceHome was the only one that had VerboseSecurity installed, which monkeypatches something in the security machinery. I wondered if there was a conflict. To test this theory, I removed VerboseSecurity and restarted zope. Problem gone.

BUt that's not the end of the weirdness. I re-installed VerboseSecurity, restarted again - and everything still works :-0

So I have no idea what the culprit was.

My Googling ability is weak this fine Monday morning...so I have a quick question. If I have a lines property in a folder, and it has values in it, what do I use to take a value from an input form field and append it to that lines list property on the containing folder? Using DTML but Python equivalent would also be greatly appreciated. Jsut need a kick in the right direction. Thanks

Allen wrote:

Using DTML but Python equivalent would also be greatly appreciated. Jsut need a kick in the right direction.

object.your_property.append(your_new_value) cheers, Chris

Well then what do you suggest as the best way to do this? This is what I came up with and seems to work: --day1 is the lines property-- --textfield is the field from the form-- --jobfair200310 is the folder-- <dtml-if Submit> <dtml-if textfield> <dtml-call "REQUEST.set('day1',day1)"> <dtml-call "day1.append(textfield)"> <dtml-call "day1.sort()"> <dtml-call expr="jobfair200310.manage_changeProperties({'day1' : day1})"> </dtml-if> </dtml-if> Thanks --Allen Dieter Maurer wrote:

Chris Withers wrote at 2003-9-17 13:00 +0100:

...

Allen wrote:

...

Using DTML but Python equivalent would also be greatly appreciated. Jsut need a kick in the right direction.

object.your_property.append(your_new_value)

*DON'T*!!!!!!!!!!!!!!!

*NEVER* modify properties with something else than the official API!

Following Chris' suggestion would seem to work but when your object is flushed from the ZODB cache, your chance it high that the modification will disappear again.

Reason: the persistent object did not recognize that one of its attributes has been modified. Therefore, it does not make the change persistent.

Dieter

Allen wrote:

Well then what do you suggest as the best way to do this?

Sorry, Dieter was right, you can do what I did, but you'd need to do: object.your_property.append(your_new_value) object.your_property._p_changed=1 ...which you can't do in protected code like python scripts.

<dtml-if Submit> <dtml-if textfield> <dtml-call "REQUEST.set('day1',day1)"> <dtml-call "day1.append(textfield)"> <dtml-call "day1.sort()"> <dtml-call expr="jobfair200310.manage_changeProperties({'day1' : day1})"> </dtml-if> </dtml-if>

This isn't bad, but it'd be a lot neater as a python script ;-) request=context.REQUEST if request.get('Submit'): textfield = request.textfield if textfield: day1 = context.day1 day1.append(textfield) day1.sort context.jobfair200310.manage_changeProperties(day1=day1) cheers, Chris

Synopsis: One ZEO server, two ZEO clients, same code installed on all three. One client gives an ImportError on a custom product, the other does not. Detail: I currently have a production site running from two zope instances, each running on its own boxes, both running from the same zeo (on its own box). I upgraded them all last night to Zope 2.6.2 / ZEO from ZODB-3.1.2 and that's when the problem appeared. The error is triggered by this line in a Script (Python): from Products.CTIPortalData import ExprEvaluator ...Which is fine on ONE of the zeo clients, but on the other, I get: Traceback (innermost last): Module ZPublisher.Publish, line 49, in publish Module ZPublisher.mapply, line 32, in mapply Module ZPublisher.Publish, line 38, in call_object Module Shared.DC.Scripts.Bindings, line 250, in __call__ Module Shared.DC.Scripts.Bindings, line 270, in _bindAndExec Module Products.PythonScripts.PythonScript, line 270, in _exec Module Script (Python), line 10, in cook_vars - <PythonScript at /portals/portal_skins/custom/cook_vars> - Line 10 Module AccessControl.ZopeGuards, line 127, in guarded_import ImportError: import of "ExprEvaluator" from "Products.CTIPortalData" is unauthorized. You are not allowed to access ExprEvaluator in this context I have checked and double-checked, and both zopes have *exactly* the same Products, Extensions, and zope software installed. I'm now going to check yet again... Also, this is the same zope / zeo versions that I've been running stably on my dev servers. As I earlier noted in another thread, I had the same problem (with the same script & product) at one point on the dev servers. I made a guess that VerboseSecurity might be part of the problem, which proved not to be true, but led indirectly to the symptom vanishing as described below. (In this case, VerboseSecurity is not involved at all - it's not on these production servers. Neither have I set ZOPE_SECURITY_POLICY="PYTHON".) previous weird experience follows from an earlier thread:

FWIW, I recently started getting this exception on some of my own code that had been working - and has NOT been changed. It started when I upgraded from 2.6.2b3 to 2.6.2b5. BUt that can't have been the culprit because weirdly, another InstanceHome running off the same SoftwareHome did NOT experience the errors. I made sure that the affected Product code was identical in the two instances - I copied it back from the working one to the non-working one. No change.

I eventually realized that the error-stricken InstanceHome was the only one that had VerboseSecurity installed, which monkeypatches something in the security machinery. I wondered if there was a conflict. To test this theory, I removed VerboseSecurity and restarted zope. Problem gone.

BUt that's not the end of the weirdness. I re-installed VerboseSecurity, restarted again - and everything still works :-0

So I have no idea what the culprit was.

--

Paul Winkler http://www.slinkp.com

I'm wondering if there's an odd bug in zope 2.6.2 that only shows up in some marginal circumstances... or maybe this is a peculiar manifestation of some bug in redhat glibc... or maybe i just haven't found my own mistake yet :-) -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's ESOTERICALLY IMPOTENT BLIND NINJA! (random hero from isometric.spaceninja.com)

Paul Winkler wrote:

I'm wondering if there's an odd bug in zope 2.6.2 that only shows up in some marginal circumstances... or maybe this is a peculiar manifestation of some bug in redhat glibc... or maybe i just haven't found my own mistake yet :-)

Try doing a diff all your code, see if there's a security declaration made on one client that isn't made on the other... Chris