aq_explicit permission: where set?
I'm testing the new sitemap method http://zope.org/Members/mwr/python_zpt_sitemap_zen and I get the following error: "You are not allowed to access aq_explicit in this context" I'm logged in as a manager. Where in ZMI can I allow aq_explicit? -- Milos Prudek
Milos Prudek wrote:
I'm testing the new sitemap method
http://zope.org/Members/mwr/python_zpt_sitemap_zen
and I get the following error:
"You are not allowed to access aq_explicit in this context"
I'm logged in as a manager.
Install Shane's VerboseSecurity product and see if you can can get soem more helpful information ;-) Chris
Install Shane's VerboseSecurity product and see if you can can get soem more helpful information ;-)
Your advice was quite helpful. Now I got this: Error Type: Unauthorized Error Value: The container has no security assertions. Access to 'aq_explicit' of (BrowserIdManager instance at 89285e0) denied. Here's the offending piece of Python Script: def isAFolder(obj): return hasattr(obj.aq_explicit, 'isPrincipiaFolderish') 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? -- Milos Prudek
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
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?
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...
Thanks, I'll try that. -- Milos Prudek _________________ Most websites are confused chintzy gaudy conflicting tacky unpleasant... unusable. Learn how usable YOUR website is! http://www.spoxdesign.com
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
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. -- Paul Winkler http://www.slinkp.com
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.
[Paul Winkler]
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.
Chris Withers wrote:
Shane, any ideas?
Nope. I suspect VerboseSecurity wasn't really a factor. Shane
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:
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
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
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
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 at 2003-9-18 07:50 -0400:
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>
That's almost fine. You do not need the "REQUEST.set", though. It does not harm but it is unnecessary. You can (and probably should) use "...manage_changePropeties(day1= day1)". 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
On Mon, Sep 15, 2003 at 09:38:03AM -0400, Shane Hathaway wrote:
[Paul Winkler]
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.
Chris Withers wrote:
Shane, any ideas?
Nope. I suspect VerboseSecurity wasn't really a factor.
It certainly seems unlikely. It was installed on the affected InstanceHome for months before I started getting these errors. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's THE IDIOT SILLIPHONT! (random hero from isometric.spaceninja.com)
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 at 2003-9-25 11:02 -0400:
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. ... from Products.CTIPortalData import ExprEvaluator
...Which is fine on ONE of the zeo clients, but on the other, I get: ... 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
Activate Zope logging (--> doc/LOGGING.txt) and look at the log file. Often, there are startup problems (missing shared library not installed or something like this) that cause products to be only partially imported. As a consequence some security declarations may not have been executed. Dieter
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
participants (6)
-
Allen -
Chris Withers -
Dieter Maurer -
Milos Prudek -
Paul Winkler -
Shane Hathaway