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
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 <bitz@bitdance.com> 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 - Zope-Dev@zope.org 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 )
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
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
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
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 <bitz@bitdance.com> 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
participants (2)
-
R. David Murray -
Steve Spicklemire