[Zope-dev] Zope 2.5: User limit for Local Security Role assignment list
One of the things Zope 2.5 is going to do is limit the answers that are available from a user folder when presenting the local role dialog; this will prevent humongous lists from displaying and instead show a simple text box where a user ID can be typed. However, for existing user folders, this poses a question of: what's the reasonable number of users to list without having to go adjust a property on the folder? The revised implementation will let you tune how many users to display before putting up an input box; but currently I've just defaulted it to 'old behavior' -- ie show all the possible users. Maybe a better thing to do would be to define a default of 250 or so. This would probably be large enough to not impact most sites, yet small enough to make it meaningful for those sites that do have enormous user folders. It is also worth pointing out that local role assignment code doesn't enforce that the users for whom it has local roles exist in any current database; it is possible to grant rights to nonexistent users. Before the ability to enter a name in directly was available, you would have had to explicitly change the form values manually -- but this exposes the problem. I dont think it poses a problem (ie I dont believe Zope has ever tried to define a mechanism whereby objects are notified that a user for whom they have permissions has been deleted.) ___ 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] how to accept an arbitrary parameter/anti-NIMDA script
You can use a **kw argument in a Python Script. Florent Guillaume Nuxeo marc lindahl [EMAIL PROTECTED] wrote: I'm looking at how to get this anti-NIMDA script to work in zope ( http://pc.xs4all.nl/default.ida) The thing is, it's called with a parameter (trying to cause a buffer overflow). For example: /default.ida?XXX X%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3% u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u%u00=a That site has a default.ida which will pass back a perlscript that turns off that particular machine's virus under certain cases... sounds like a good thing. But how can I get an object called default.ida to accept anything passed after the ? and what kind of object (python script?) should it be? ___ 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 ) -- Florent Guillaume, Nuxeo SARL (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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] Re: [Zope] Z SQL Methods appear broken in 2.4.x
This works for me (Zope 2.4 branch, ZMysqlDA). Do you have a traceback ? Andreas - Original Message - From: Joseph J Wolff [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, September 28, 2001 15:56 Subject: [Zope] Z SQL Methods appear broken in 2.4.x It appears that Z SQL Methods are broken in 2.4.x. Specifically, the type=string in a dtml-sqlvar is broken - a simple ZSQL query such as: select id, cost, name from choices where name = dtml-sqlvar nam type=string results in the following error: exceptions.NameError: global name 'string' is not defined It's broken on 2.4.0 and 2.4.1, and works fine on 2.2.5, 2.3.0, and 2.3.2 - in fact, it's in production on our 2.2.5. Integer parameters work fine. It's hard to believe that no one else has run into this, and that the stable 2.4.x branch has gotten this far without anyone noticing this - I've even tried it on 2 different servers running Zope 2.4 (2.4.1 on FreeBSD 4.0, our production web server, and 2.4.0 on FreeBSD 4.3, our dev server) Any ideas? Regards, joe Joseph J Wolff eRacks Open Source Rackmount Systems www.eracks.com [EMAIL PROTECTED] ___ Zope maillist - [EMAIL PROTECTED] http://lists.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope-dev ) ___ 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 )
SV: [Zope-dev] Web Services for Zope
Well... the status is that I'm trying to work on it on an as-possible basis :) The problem is that it hasn't been very possible for the last few weeks. If you just need to generate WSDL and you're willing to live on the bleeding edge and use some code that might still change a lot in the future to get the job done, let me know and I'll be happy to send you a snapshot of what I have... Why don't you put into the public CVS instead? /Magnus ___ 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] python 2 Win32 binary for LocalFS
Does anyone have the win32wnet.pyd work with python2? Can someone upgrade the localfs product? Or are there better replacement available? Rgs, Kent Sin __ Do You Yahoo!? Listen to your Yahoo! Mail messages from any phone. http://phone.yahoo.com ___ 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] KeyError on UnIndex.keyForDocument
I had something like that. It turned out that I was doing a catalog query, sorting on an index that didn't exist on some of the objects. I made sure the index existed on all my objects. But still I'd be inclined to consider this a bug. Florent Guillaume Nuxeo Morten W. Petersen [EMAIL PROTECTED] wrote: Hia, While trying to reindex an entire catalog an error is raised, which looks like this: Traceback (innermost last): File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py, line 223, in publish_module File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py, line 187, in publish File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Zope/__init__.py, line 221, in zpublisher_exception_hook (Object: api) File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py, line 171, in publish File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/mapply.py, line 160, in mapply (Object: update_instances) File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/ZPublisher/Publish.py, line 112, in call_object (Object: update_instances) File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/WarpFramework/catalog.py, line 438, in update_instances (Object: api) File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/WarpFramework/catalog.py, line 195, in __call__ (Object: Traversable) File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/ZCatalog/ZCatalog.py, line 535, in searchResults (Object: Traversable) File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/ZCatalog/Catalog.py, line 666, in searchResults File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/Products/ZCatalog/Catalog.py, line 614, in _indexedSearch File /home/morten/zope_instances/usr2/local/Zope-bcr/lib/python/SearchIndex/UnIndex.py, line 453, in keyForDocument KeyError: (see above) Any clues? Thanks a whole bunch, Morten ___ 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 ) -- Florent Guillaume, Nuxeo SARL (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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] testing types in PythonScripts
I have a variable, f. The value of f might be a list, or it might be a string. I want to do different things to f depending what type it is. How do I check its type from a PythonScript? I can't use type(), as this opens up a security hole with Extension Classes, where the type is the class. I can't import types, as that seems to be restricted. I suggest that either one or both of the following be altered: * The types module is allowed to be imported into restricted stuff. * A safe version of type() is put into the restricted global namespace. I seem to recall a discussion of this a few months ago, where someone (Evan?) proposed a safe version of type(). I guess this got lost in the conversion to RestrictedPython with Zope 2.4. Oh yeah... an ugly workaround is to try to append to f and see if you get and AttributeError. -- Steve Alexander Software Engineer Cat-Box limited ___ 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] Zope on Windows/Mac OS X: BatteriesIncludedDistribution
Whew, what a proposal and what a good sign! As several have noted, there are quite a few proposals in the fishbowl that deal with different aspects of the problems. There's also a draft proposal that we had here in ZC that expands on the items. Finally, there appear to be a few pieces of software (yours, zctl, zopectl, etc.) that try to address aspects. I suggest that we all spend some time trying to revisit all the proposals, obsolete the ones that are covered elsewhere, and try to find the common ground. There is a dorman zope-packagers mailing list we could hijack for these purposes: http://lists.zope.org/pipermail/zope-packagers/ I think, with all the various efforts, it is time to agree on some standards regarding where configuration data lives and how it looks. --Paul Richard Jones wrote: I've just created the follwing fishbowl proposal: http://dev.zope.org/Wikis/DevSite/Proposals/BatteriesIncludedDistribution Please read and comment. Richard ___ 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 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] testing types in PythonScripts
Python Script has a same_type(x,y) function. Florent Guillaume Nuxeo Steve Alexander [EMAIL PROTECTED] wrote: I have a variable, f. The value of f might be a list, or it might be a string. I want to do different things to f depending what type it is. How do I check its type from a PythonScript? I can't use type(), as this opens up a security hole with Extension Classes, where the type is the class. I can't import types, as that seems to be restricted. I suggest that either one or both of the following be altered: * The types module is allowed to be imported into restricted stuff. * A safe version of type() is put into the restricted global namespace. I seem to recall a discussion of this a few months ago, where someone (Evan?) proposed a safe version of type(). I guess this got lost in the conversion to RestrictedPython with Zope 2.4. Oh yeah... an ugly workaround is to try to append to f and see if you get and AttributeError. -- Steve Alexander Software Engineer Cat-Box limited ___ 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 ) -- Florent Guillaume, Nuxeo SARL (Paris, France) +33 1 40 33 79 87 http://nuxeo.com mailto:[EMAIL PROTECTED] ___ 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] Re: [DISCUSS] Committer agreement not even handed and threadening
Dieter Maurer wrote: Paul Everitt writes: http://dev.zope.org/CVS/Contributor.pdf The Committer Agreement does not seem to be even handed: The committer transfers rights immediately and indefinitely to Zope Corporation (the contributions become a gift to Zope Corporation). This is an inaccurate representation. Transfer means you lose the rights and we gain the rights. Under joint ownership, both have rights. I think this point was abundantly clear, so I'm surprised to see you portray this as a gift. The agreement states explicitly that no rights are transfered to the committer. Because they never lost any rights. This is not a problem in itself. However My intention to contribute would be to strengthen the Open Source Movement. A statement that the supported code base (Zope) will remain open source and that committers will be able to use it (indefinitely) under terms comparable to the current ZPL would help to let the agreement to appear more balanced I don't think it's really feasible to 100% guarantee things in the future. Rather, the agreement states that current code, and any contribution, will be available under the ZPL. Nothing can be retracted. If someone comes along and gives us one trillion dollars to stop releasing our work as open source, two things would happen: 1) First, we'd take the money. :^) 2) Second, all the existing code has to remain available under the ZPL. We just wouldn't do _new_ things under a ZPL. This is part of the safety of joint ownership. If you don't like what we do in the future, you still have rights on your contribution. The Commitrer Agreement is quite threadening: A committer takes over a considerable risk (complete warranty and indemnification with respect to intellectual rights infringement). Yes. You can't make the risk disappear. Someone has to bear the risk. It makes zero sense for ZC to bear the risk of what goes on in someone else's brain. Even in the scenario of carelessness, a case will have to be made regarding what you knew and when you knew it. The risk is far higher than that of a (german) employee. German employment law recognizes that * all people make (sometimes) errors * coping with isolated errors is far easier for a larger community (the big employer) than a single individual. Therefore, it uses the term Fahrlässigkeit (carelessness). An employee has to take all care to not make errors during his work. If something bad happens due to slight carelessness (leicht fahrlässig), then this is a general risk which has to be taken by the employer. If serious carelessness (grob fahrlässig) was the cause, then the employee has to take the consequences for himself. We should have something similar for the committer agreement (not restricted to intellectual property rights!). Maybe something like an insurance for slight carelessness cases... Unfortunately we'd have to be the insurer. :^( Otherwise, commiting anything might easily ruin an individual. Instead, you'd prefer that it ruin ZC? Or are you asserting that somehow we could make it so that nobody would be held accountable? Especially with the strange US Patent Laws (where almost everything (such as presenting information in a popup window or integrating a Web Frontend with a baking oven) can be patented) and incredibly high damages amounts (5 billion for a smoker who got cancer) assigned in US courts. Unfortunately that's the jurisdiction in which we operate. --Paul ___ 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 )
