hack for refused authorization with virtual dataskin
Hello, After rereading the ZopeSecurityPolicy source code, I tried the following hack. I add in the skinscript : WITH 1 COMPUTE __allow_access_to_unprotected_subobjects__=RESULT which does work : it fools the security mechanism. I can live with it but feel that there is only a slight problem which could allow me to avoid the hack. I hope this can hint some of you to help me to understand what is badly settled in my installation. -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 30 1348 Louvain-la-Neuve Belgium Tel 010 457490 Mob 0477 363942 TVA 467 093 008 RC Niv 49849
At 01:37 PM 4/23/01 +0200, Godefroid Chapelle wrote:
Hello,
After rereading the ZopeSecurityPolicy source code, I tried the following hack.
I add in the skinscript :
WITH 1 COMPUTE __allow_access_to_unprotected_subobjects__=RESULT
which does work : it fools the security mechanism.
I can live with it but feel that there is only a slight problem which could allow me to avoid the hack.
I hope this can hint some of you to help me to understand what is badly settled in my installation.
It sounds to me like you need to be using the getId() method instead of the .id attribute. I think that the id attribute is being phased out in favor of getId(). I'm somewhat reluctant to enable access to unprotected subobjects in the DataSkin base class; it seems a little too broad of an access level. The other alternative would be to allow SkinScript expressions free rein as regards security - but that's too broad also. The optimum would be to allow SkinScript expressions full access to the targeted DataSkin's direct attributes, but normal (validated) access to everything else, but I'm not sure how to do this safely. This is an example of why I consider ZPatterns a hack - too many places where it depends on Zope innards like this.
"Phillip J. Eby" a écrit :
It sounds to me like you need to be using the getId() method instead of the .id attribute. I think that the id attribute is being phased out in favor of getId().
I was already told about the getId but the problem goes further than access to the id. I get the same non authorized message when accessing other attributes computed by the skinscript. I do not understand why I have no problem (I mean do not need access_to_unprotected hack) with standard stored ZClass-dataskin instances but well with non stored instances... I suppose there is something different between the two cases going on during the construction of the instances but have not been able until now to get the point. My Python is not fluent enough to allow me to understand the following code of Rack.py : _v_itemConstructor = ComputedAttribute(lambda s, v=ComputedAttribute(_v_itemConstructor): v)
I'm somewhat reluctant to enable access to unprotected subobjects in the DataSkin base class; it seems a little too broad of an access level. The other alternative would be to allow SkinScript expressions free rein as regards security - but that's too broad also. The optimum would be to allow SkinScript expressions full access to the targeted DataSkin's direct attributes, but normal (validated) access to everything else, but I'm not sure how to do this safely.
This is an example of why I consider ZPatterns a hack - too many places where it depends on Zope innards like this.
I get your point but I think that something a la ZPatterns should be integrated in the Zope core to separate logic and storage especially now that ZPT allow a very clean separation between logic and presentation. I would appreciate to know the position of DC about the design objectives of ZPatterns -- Godefroid Chapelle BubbleNet sprl rue Victor Horta, 30 1348 Louvain-la-Neuve Belgium Tel 010 457490 Mob 0477 363942 TVA 467 093 008 RC Niv 49849
participants (2)
-
Godefroid Chapelle -
Phillip J. Eby