Re: [Zope-dev] EMarket and 2.2.0b3
On Sat, 1 Jul 2000, Adam Karpierz wrote:
> In installation of Zope Emarket and eTailer both installed
> and works ok on current 2.2.0 CVS.
Well, they may work OK, but there's still a problem.
> Then you should update some files from current CVS.
I did a full current CVS checkout, and if I access '/manage_main' I still
don't get prompted for a password. Can you check to see if that happens
for you, as well? Remember, call that URL as the first thing you do
in the browser session. You ought to get prompted for a manager login,
but in my case I just get to see the directory listing, as if it
were viewable by Anonymous.
> In original version of 2.2.0b3 Emarket and eTailer even dont install
> correctly in my testing box (Win98).
Funny, I didn't have any install problems with b3.
Before I tried the CVS thing, I did some tracing under b3. I'm
beyond my Zope Zen level here, so maybe someone else can point me
in the right direction to follow up on what I've found. What I
did was to run Zope under debug and simply trace the execution of
publishing the URL "/manage_main" both with and without EMarket
installed. I then diffed the results and looked at the place where
the execution path diverges. It happens at line 369 of BaseRequest.py,
in the traverse function:
r = getattr(subobject, '__roles__', UNSPECIFIED_ROLES)
When EMarket is not installed, the next thing that happens is a
call to __of__ in PermissionRole.py. This returns ('Manager',),
and so the page is protected. If EMarket is installed, execution
continues immediately with line 370 of BaseRequest.py, making r
UNSPECIFIED_ROLES, and so I guess the page is not protected.
Given my limited understanding of what __of__ represents, I presume
this means that somehow the management method has become unwrapped
from its aquisition context after EMarket is installed? But even
if I'm right about that I don't know where to go from here in
tracking down how it happens. I tried to set a breakpoint at line
169 so I could inspect the object being manipulated, but I can't
seem to get the debugger to stop at that line. I hit 'c' and it
just displays the page (or error message, depending on whether or
not EMarket is installed).
Can anyone point me in a useful direction? Do I need to study the
aquisition module source code next? Or suggest what I might be
doing wrong in setting the breakpoint in the debugger (I just do
'b ZPublisher/BaseRequest.py:169' and it *seems* happy with it...)
--RDM
___
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] EMarket and 2.2.0b3
Hi David, I think the design is flawed from the outset and should be changed. Basically I was trying to have my cake and eat it too with this one... and the solution (iterating through the folder class's manage_options and slapping on my own was goofy anyway...) but there's really no need. I'm moving MarketItem to a ZClassable object anyway where this can by much more simply done with 'Views'. The thing I haven't figured out is how to make the MarketItem ZClasses available only inside a MarketItemsFolder. I'm thinking I may have to make ZClasses for everything, but define the 'enclosed' ZClasses inside the enclosing ZClasses. Also.. ZPatterns may affect this as well. I'm looking into making all these things 'DataSkins' so that the actual instance data can be kept in a very flexible way, but in ZODB by default. ZPatterns looks really cool.. I feel sometimes like a kid looking at a magic trick... sure that once I really get into it I'll understand, but somehow not sure that it might *really* just be magic after all. ;-) -steve > "RDM" == R David Murray <[EMAIL PROTECTED]> writes: RDM> On Fri, 30 Jun 2000, R. David Murray wrote: >> Darn, I should have done more testing. I only fixed the prompt >> for permissions problem. manage_workspace still goes to the >> import/export screen...back to the testing. RDM> Arg, it's worse than I thought. My original test was broken. RDM> I haven't found the problem at all. So please ignore all my RDM> recent posts about this and I'll crawl back under my rock and RDM> do some more careful testing. RDM> --RDM ___ 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] EMarket and 2.2.0b3
On Fri, 30 Jun 2000, R. David Murray wrote: > Darn, I should have done more testing. I only fixed the prompt > for permissions problem. manage_workspace still goes to the > import/export screen...back to the testing. Arg, it's worse than I thought. My original test was broken. I haven't found the problem at all. So please ignore all my recent posts about this and I'll crawl back under my rock and do some more careful testing. --RDM ___ 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] EMarket and 2.2.0b3
On Fri, 30 Jun 2000, R. David Murray wrote: > manage_options.append(copy(item)) > > makes the management interface behave normally with the product installed. Darn, I should have done more testing. I only fixed the prompt for permissions problem. manage_workspace still goes to the import/export screen...back to the testing. --RDM ___ 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] EMarket and 2.2.0b3
On Thu, 29 Jun 2000, Steve Spicklemire wrote: > I'm sure a lot of this is because EMarket was a 1.x product that has > seen relatively little change, in basic structure, since. I'm working It doesn't look that way, actually. > on some patched to allow (1) ZClasses to act as MarketItems and > Shoppers and (2) ZPatterns integration so that most objects can > be optionally stored in RDBM or ZODB. .. I'll go ahead and > checkin my ZClass stuff. I'm not running 2.2x much, since I'm This would be really great, thanks. > really busy on other development... but I can at least > see if the product installs! ;-) I figured out a way to fix the problem I was seeing, but I don't really understand why it caused the problem, though it does not seem unreasonable that it did (which is why I thought to experiment in this area of the code). MarketItem.py has the following code snippet near the beginning of the class definition: for item in OFS.Folder.Folder.manage_options: if item['label'] == 'Contents': manage_options.append(copy(item)) # be sure to muck with a *copy* manage_options[-1]['action'] = 'manage_contents' else: manage_options.append(item) Changing the last line to manage_options.append(copy(item)) makes the management interface behave normally with the product installed. It does not seem unreasonable to me to not make copies of things not being changed: why clutter up memory with copies? But clearly there are unexpected interactions later because of this, interactions that produce obvious strange behavior in 2.2.0 but seem to work fine in 2.1.x. I don't know if this has any security implications someone from DC should look at, but it's probably worth a note in the product author's security guide. I also have no idea whether or not the similar eTailor problem has a similar cause and solution. --RDM ___ 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] EMarket and 2.2.0b3
I'm sure a lot of this is because EMarket was a 1.x product that has seen relatively little change, in basic structure, since. I'm working on some patched to allow (1) ZClasses to act as MarketItems and Shoppers and (2) ZPatterns integration so that most objects can be optionally stored in RDBM or ZODB. .. I'll go ahead and checkin my ZClass stuff. I'm not running 2.2x much, since I'm really busy on other development... but I can at least see if the product installs! ;-) -steve > "RDM" == R David Murray <[EMAIL PROTECTED]> writes: RDM> OK, so I didn't get very far in tracking down what inside RDM> EMarket is triggering the wierd auth behavior, because I had RDM> to run a bunch of tests against b3, where the behavior has RDM> changed from that of b2. RDM> For this testing my method of determining if "things are RDM> weird" is to see if I get prompted for authentication if I RDM> access the "/manage_main" URL. Weird means I don't get RDM> prompted. RDM> Under b2, installing EMarket with a dummy empty __init__.py RDM> file caused the weird behavour. Under b3, that test does RDM> not. However, the EMarket __init__.py file with any of the RDM> imports for the submodules uncommented *does* cause the weird RDM> behavior. Farther than that I haven't gotten yet. RDM> My tests give me some other interesting things to report, RDM> however. After installing b3, I confirm that the site is RDM> working and I can view the root index_html file normally. If RDM> I then copy my test Data.fs from the b2 installation, the b3 RDM> instance fails to show the root index_html, giving an error RDM> message of a key error on URL on the last line of traverse in RDM> BaseRequest.py. Now here's the weird thing: if I then RDM> *delete* the Data.fs file, and restart Zope, *I continue to RDM> get that same error*. I didn't try to track that any RDM> further, but it unnerves me. RDM> Second, the patch, supplied by someone else, that I reposted RDM> here that fixed the "a_" KeyError after EMarket was installed RDM> in b2, if applied to b3 *causes* that "a_" error to appear. RDM> Since this patch was reportedly added to the CVS, I think RDM> there is something here that needs to get cleared up before RDM> 2.2 final. RDM> I'll work on this some more tomorrow, but so far I'm nowhere RDM> near finding what code might be involved in this set of RDM> errors. RDM> Has anyone seen the aforementioned "weird problem" with any RDM> products other than EMarket and eTailor? RDM> --RDM RDM> ___ Zope-Dev RDM> maillist - [EMAIL PROTECTED] RDM> http://lists.zope.org/mailman/listinfo/zope-dev ** No cross RDM> posts or HTML encoding! ** (Related lists - RDM> http://lists.zope.org/mailman/listinfo/zope-announce RDM> 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] EMarket and 2.2.0b3
OK, so I didn't get very far in tracking down what inside EMarket is triggering the wierd auth behavior, because I had to run a bunch of tests against b3, where the behavior has changed from that of b2. For this testing my method of determining if "things are weird" is to see if I get prompted for authentication if I access the "/manage_main" URL. Weird means I don't get prompted. Under b2, installing EMarket with a dummy empty __init__.py file caused the weird behavour. Under b3, that test does not. However, the EMarket __init__.py file with any of the imports for the submodules uncommented *does* cause the weird behavior. Farther than that I haven't gotten yet. My tests give me some other interesting things to report, however. After installing b3, I confirm that the site is working and I can view the root index_html file normally. If I then copy my test Data.fs from the b2 installation, the b3 instance fails to show the root index_html, giving an error message of a key error on URL on the last line of traverse in BaseRequest.py. Now here's the weird thing: if I then *delete* the Data.fs file, and restart Zope, *I continue to get that same error*. I didn't try to track that any further, but it unnerves me. Second, the patch, supplied by someone else, that I reposted here that fixed the "a_" KeyError after EMarket was installed in b2, if applied to b3 *causes* that "a_" error to appear. Since this patch was reportedly added to the CVS, I think there is something here that needs to get cleared up before 2.2 final. I'll work on this some more tomorrow, but so far I'm nowhere near finding what code might be involved in this set of errors. Has anyone seen the aforementioned "weird problem" with any products other than EMarket and eTailor? --RDM ___ 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 )
