Re: [Zope-dev] RFC ZTK: Change zope.app.wsgi to set REMOTE_USER
On Jan 10, 2012, at 10:17 AM, Jim Fulton wrote: > BTW, zope.app.wsgi isn't in the ZTK. :) It's not in ztk-versions.cfg, but it is in zopeapp-versions.cfg. That's still part of ZTK package. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New zc.queue release?
On Dec 18, 2011, at 5:52 AM, Marius Gedminas wrote: > One thing leaves me baffled: how was it possible to make the release to PyPI > (which means at the very least python setup.py sdist upload) if python > setup.py had that missing import? Because buildout was used: ./bin/buildout setup . sdist register upload Since ./bin/buildout imports zc.buildout.buildout which imports os it worked. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New zc.queue release?
On Dec 17, 2011, at 7:13 PM, Maurits van Rees wrote: > There is a problem with the setup.py of 1.2 though: 'import os' is missing so > it cannot be used. I have fixed it on trunk. Could you release a new > version? Done. zc.queue-1.2.1 is now on PyPI. P.S. Lessons learned: 1. Run "pyflakes .", not "pyflakes src". 2. Improving setup.py is not an improvement if done in a hurry and one forgets a crucial import. :-) Best regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New zc.queue release?
On Dec 17, 2011, at 5:40 PM, Zvezdan Petkovic wrote: > I'll review and release. Done. zc.queue-1.2 is on PyPI. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] New zc.queue release?
On Dec 16, 2011, at 10:57 PM, Maurits van Rees wrote: > Can someone create a new release of zc.queue? zvezdan and gary are owners on > PyPI. I'll review and release. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.folder/trunk/ Conform to repository policy
On Nov 29, 2011, at 4:05 PM, Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 11/29/2011 11:48 AM, Gediminas Paulauskas wrote:
>> -- Forwarded message ------ From: Zvezdan Petkovic
>> Date: 2011/2/2 Subject: Re: [Checkins] SVN:
>> zope.app.folder/trunk/ Conform to repository policy To: Gediminas
>> Paulauskas
>>
>>
>> I noticed your checkins similar to this:
>>
>> On Dec 28, 2010, at 2:12 PM, Gediminas Paulauskas wrote:
>>
>>> Log message for revision 119203: Conform to repository policy ...
>>> Modified: zope.app.folder/trunk/setup.py
>>> ===
>>> --- zope.app.folder/trunk/setup.py2010-12-28 17:10:33 UTC (rev
>>> 119202) +++ zope.app.folder/trunk/setup.py2010-12-28 19:12:47
>>> UTC (rev 119203) @@ -1,6 +1,6 @@
>>> ##
>>>
>>>
> #
>>> -# Copyright (c) 2006 Zope Corporation and Contributors. +#
>>> Copyright (c) 2006 Zope Foundation and Contributors.
>>
>>
>> This is right. The copyright holder is the Foundation now.
>>
>>
>>> # All Rights Reserved. # # This software is subject to the
>>> provisions of the Zope Public License, @@ -21,13 +21,13 @@ def
>>> read(*rnames): return open(os.path.join(os.path.dirname(__file__),
>>> *rnames)).read()
>>>
>>> -version = '3.5.2 dev' +version = '3.5.2dev'
>>>
>>> setup(name='zope.app.folder', version=version, - author='Zope
>>> Corporation and Contributors', + author='Zope Foundation and
>>> Contributors',
>>
>>
>> This is NOT right. This code was written in Zope Corporation and that
>> does not change with the transfer of the copyright. The author is not
>> equal to the copyright holder.
>>
>> Please read this thread here and Christian Theune admission that he
>> was wrong about checking for author in his conformance scripts.
>>
>> https://mail.zope.org/pipermail/zope-dev/2010-May/040514.html
>>
>> So, can we please stop changing authors.
>
> For the package in question here ('zope.app.folder'), ZC is in *now* way an
> author: 'svn log' says that the majority of people who ever checked into the
> package was not ZC employees at any point. That change was from one piece of
> boilerplate (used when ZC was the copyright holder) to another piece (after
> the transfer). For such a collectively-originated work, the ZF is a much
> better placeholder than ZC: it exists to represent the collective interests
> of the Zope development community.
Read the whole message, please. It starts with:
"I noticed your checkins similar to this:"
It's not just this one package that was in question.
The link above leads to a thread that shows that author change was wrongly
enforced. As a result, many packages had author changed to ZF even when not
needed.
So, can we please stop changing authors.
Zvezdan
P.S. Just for the record:
Gediminas asked at the time should he revert the change above
and I said: NO.
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] access to create z.i and z.c releases
On Sep 23, 2011, at 3:36 AM, Chris Withers wrote: > I just tried zope.interface 3.8.0 on MacOS X Lion and got: > > Getting distribution for 'zope.interface'. > unable to execute gcc-4.0: No such file or directory > > WARNING: > > An optional code optimization (C extension) could not be compiled. > > Optimizations for this package will not be available! > > command 'gcc-4.0' failed with exit status 1 > > > Not seen that before, definitely got gcc: > > $ which gcc > /usr/bin/gcc > > $ gcc --version > i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build > 5658) (LLVM build 2335.15.00) > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > ...not sure why it wants gcc-4.0 specifically, any ideas? Probably because your Python executable was built with it. Distutils tries to build with the same flags, architecture, etc. Did you build your python (used to build zope.interface) on Lion, or before you upgraded to Lion? Did you install a 32-bit version of python perhaps? Did you upgrade XCode when you upgraded to Lion. Those are just some possible causes, not necessarily what's really happening on your machine. Also, I'm just guessing from experience with previous upgrades on Mac, I'm not running Lion yet. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] kudos...
On Aug 8, 2011, at 4:44 PM, Chris McDonough wrote: > Kudos to whomever turned the "transaction" package's transaction manager into > a context manager and was thoughtful enough to provide the "attempts" method > (which returns a separate context manager, wrapping the txn context manager, > and retries some number of configurable times). > This makes writing code that integrates with a web system that commits > or aborts as easy as: > > import transaction > > for attempt in transaction.attempts(attempts): >with attempt as t: >response = handler(request) > >if t.isDoomed(): >t.abort() > >if commit_veto is not None: >veto = commit_veto(request, response) >veto and t.abort() > >return response > > Very nice. > > - C Yes, this is *very* convenient and I like to use it, but beware of the bug (it's not affecting you above because of the return). According to the documentation, it's intended as a replacement for: for i in range(3): try: with transaction: ... some something ... except SomeTransientException: continue else: break So, presumably, for attempt in transanction.attempts(retries): with attempt as tx: do_something() should break after the *first* successful commit. It doesn't. Instead, it commits do_something() ``retries`` times which is most probably not intended. See https://bugs.launchpad.net/transaction/+bug/724332 The patch attached to the bug report is just a test that proves that behavior is unexpected and gives a workaround. The workaround is simple enough and I prefer to use transaction.attempts convenience rather than the typical try-except code above. Still, we really should find time to fix this in the transaction manager code so that it behaves as expected. (Or change the documentation and tests). Regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Conform to repository policy.
On May 6, 2010, at 9:52 AM, Christian Theune wrote: > You're right. And I was slow and laggy. The change is in. It's been a > mis-assumption on my side to think author information being equal to > copyright ownership and I fixed that in the script. Thank you. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Conform to repository policy.
On May 6, 2010, at 9:09 AM, Tres Seaver wrote: >> Christian Theune has already mentioned that the inclusion of the author >> check in his script was a misunderstanding. >> >> If you did not see that message already it's here: >> >> https://mail.zope.org/pipermail/zope-dev/2010-April/040223.html >> >> Can we now please stop changing the author information? >> >> Otherwise, let me just repeat the question I already asked and Christian >> answered. >> >> Can you point us to the Zope Foundation bylaws >> or a policy document that requires this? >> >> I cannot find this in a contributor agreement. >> >> Best regards, > > 'Zope Corporation and Contributors' is not a reasonable value for author > here, as ZC has transferred all copyrights to the foundation. Copyright and author are two different things. ZF has the copyright. We signed that in the contributor agreement. Why exactly is "Zope Foundation and Contributors" a more reasonable value? When has Zope Foundation written a piece of code? > If you as the originial author of zope.minmax wanted to update it to have > your own name, and set the maintainer to 'Zope Foundation and Contributors', > that would be OK with me, personally. If I wanted to put my name on it I would have done it in the initial release. I was fine with having ZC as author there. However, what you or I are fine with, "personally", absolutely does not matter. What matters is whether something is right or wrong. > However, until the ZF repository commmittee (Christian, acting for the > board) updates the zope.repositorypolicy checker and fixer scripts, I'm going > to check in changes which comply with the policy as spelled out in those > scripts. So, basically you are saying that we are going to follow an admittedly wrong unilateral decision until somebody finds the time to change it? Why are we so quick to follow that policy and so slow in changing it? BTW, you still did not answer my question. Can you point us to the Zope Foundation bylaws or a policy *document* that requires this? I cannot find this in a contributor agreement. I'm sorry, but I just cannot accept a script as a legal document. Best regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.minmax/trunk/ Conform to repository policy.
On May 5, 2010, at 2:42 PM, Tres Seaver wrote: > Log message for revision 112025: > Conform to repository policy. ... > setup( > name='zope.minmax', > version='1.1.3dev', > -author='Zope Corporation and Contributors', > +author='Zope Foundation and Contributors', > author_email='zope-dev@zope.org', > description=( > "Homogeneous values favoring maximum or minimum for ZODB " Christian Theune has already mentioned that the inclusion of the author check in his script was a misunderstanding. If you did not see that message already it's here: https://mail.zope.org/pipermail/zope-dev/2010-April/040223.html Can we now please stop changing the author information? Otherwise, let me just repeat the question I already asked and Christian answered. Can you point us to the Zope Foundation bylaws or a policy document that requires this? I cannot find this in a contributor agreement. Best regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope Tests: 10 OK, 4 Failed, 2 Unknown
On May 4, 2010, at 6:07 AM, Martijn Faassen wrote: > For a while already people have been making changes that at least break > tests on 2.4. For instance, zope.testing has some facility to pretty print a > dictionary that sorts the keys, because Python 2.4's built-in pretty print > module apparently doesn't do that yet, The pprint version in Python 2.4 sorts dictionaries too, but only if they don't fit on a single line of output. > meaning random test failures can happen. But people have been updating code > to use Python's built-in pretty print facility and this will only be reliable > on Python 2.5 and higher. I already corrected one such checkin with a simple workaround. >>> pprint(somedict, width=1) This causes Python 2.4 to pretty print somedict one item per line, and thus forces it to sort it. So the tests using pprint can be made reliable on Python 2.4 to 2.6. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] SVN: ZConfig/trunk/setup.py correct metadata: I really did write this.
On Apr 9, 2010, at 10:57 AM, Fred Drake wrote: > On Fri, Apr 9, 2010 at 10:43 AM, Tres Seaver wrote: >> It seems reasonable to me that it *should* work, though I'm not sure how to >> write the code which tests that. > > See my later follow-up as well. > > In particular, while it *may* be reasonable to set the ZF as > maintainer, it's not clear that it's the right thing either. Why > shouldn't some "Grok Team" be listed as the maintainer for the grok > packages, with an appropriate email? That seems preferable to me. > > I think the *right* thing to do is update the copyrights to reflect > the copyright ownership, but not to otherwise change package metadata. Why was the check for author even included in the checker/fixer scripts? Can you point us to the Zope Foundation bylaws or a policy document that requires this? I cannot find this in a contributor agreement. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.authorizedotnet support for Automated Recurring Billing
On Apr 7, 2010, at 2:35 PM, David Glick wrote: > Understood. Now that Plone 4 is almost ready and using Python 2.6, > there are a number of Plone GetPaid users who are ready to use these > changes as soon as they're released. :) zc.ssl-1.2 and zc.authorizedotnet-1.3.1 have been tagged and released on PyPI. Regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zc.authorizedotnet support for Automated Recurring Billing
On Apr 7, 2010, at 1:33 PM, David Glick wrote: > I also need to make some updates to make zc.authorizedotnet work with > Python 2.6, as it currently depends (via zc.ssl) on ssl-for-setuptools, which > is a backport of the ssl module that ships with Python 2.6. You will not need to make those updates. I already did. :-) I have the changes ready for commit and will do that very soon. However, zc.authorizedotnet *must* continue working with Python 2.4. > Having heard no further response, I will proceed by forking the packages I > need to modify and releasing them in the z3c namespace -- but please contact > me if we can avoid that. Yes we can. As explained above, I'll commit the changes. I'm sorry for not replying immediately, but I've been *very* busy and since the thread referred to in the initial message is over two years old I didn't think this was so urgent. So, please have a little patience, I'll commit all the necessary changes that make zc.authorizedotnet, zc.ssl, and zc.creditcard Python2.4 to 2.6 compliant. Regarding the interest in the other protocol for Authorize.Net recurring payments, I think it could be a small package itself. It's a feature/protocol independent of the zc.authorizedotnet and can be seen as an additional functionality. Best regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Avoid deprecation warnings in the testrunner
On Dec 24, 2009, at 10:26 AM, Fabio Tranchitella wrote: > * 2009-12-24 16:20, Zvezdan Petkovic wrote: >> Before I release the egg on PyPI: >> >> 1. Should we release as 1.1.2 (a minor change), or >> 2. Does the removal of dependency on zope.testing warrants a >> bump to 1.2.0? > > I think 1.1.2 is okey, you are not changing any behaviour of the package. zope.minmax-1.1.2 is now on PyPI. >> FWIW, I preferred zope.testing.doctest reporting of 15 tests because >> that's the actual number of things being tested in that file, while >> Python doctest reports 1 test only, because that's a number of test files >> being run. > > Me too, maybe we should push the changes to doctest upstream to Python? That will take some serious persuading. We could argue the above, i.e., that 15 different things were tested in one doctest file. Unfortunately, when a single test in a doctest file is mixed with prose descriptions to explain parts of the test, zope.testing.doctest counts it as a separate test. This was considered a misfeature in the past and would probably be rejected for the same reason now. People are divided in opinion on this and whenever that happens it's hard to push such a change upstream into Python library. Of course, it may be worth trying if there is a critical mass of supporters. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Avoid deprecation warnings in the testrunner
On Dec 24, 2009, at 10:13 AM, Fabio Tranchitella wrote: > * 2009-12-24 15:43, Zvezdan Petkovic wrote: >> You did not import zope.testing.doctest, but the reference to it remains. >> I don't think that's a fix. > > You are right, I committed the right fix. I was just about to commit the same thing + the removal of the dependency on zope.testing in setup.py. I committed that second part now. Before I release the egg on PyPI: 1. Should we release as 1.1.2 (a minor change), or 2. Does the removal of dependency on zope.testing warrants a bump to 1.2.0? FWIW, I preferred zope.testing.doctest reporting of 15 tests because that's the actual number of things being tested in that file, while Python doctest reports 1 test only, because that's a number of test files being run. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Avoid deprecation warnings in the testrunner
On Dec 24, 2009, at 8:50 AM, Fabio Tranchitella wrote:
> I don't think we can avoid the error, and to be honest I consider the code in
> zope.minmax to be wrong.
>
> """
> import zope.testing
> x = zope.testing.doctest.DocTestFile(...
> """
>
> The import is wrong, it should be "zope.testing.doctest", and I fixed it in
> the trunk, and this was the only failure in the ZTK.
I don't think you fixed it on the trunk.
The code now looks like this
import doctest
...
zope.testing.doctest.DocFileSuite('minmax.txt'),
...
You did not import zope.testing.doctest, but the reference to it remains. I
don't think that's a fix.
Zvezdan
___
Zope-Dev maillist - Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 4:40 PM, Gary Poster wrote: > Put yet another way, how are 99+% of our "utility" usages not singletons? Therein lies the problem. Singletons are singletons in 100% of cases. Since utilities are not singletons in 100% of cases they are not singletons by definition. > If that's the case, what's the value of having to explain what a utility is? There is nothing to explain. Utility is something useful that helps you accomplish a task. Which task? Well, the one you just looked a utility for. :-) Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 4:05 PM, Zvezdan Petkovic wrote: > On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: >> 3) I also think that "utility" is a bad name. Is "singleton" two letters >> too long? > > Yes and not because "singleton" is longer. > It just a bad name. > :-) To clarify because of 1. the typo above (should be "It's just ..."); 2. the preposition "it" used. I meant: "Singleton" is a bad name. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] implementing zope.component 4.0
On Nov 30, 2009, at 2:24 PM, Gary Poster wrote: > 3) I also think that "utility" is a bad name. Is "singleton" two letters too > long? Yes and not because "singleton" is longer. It just a bad name. :-) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] various ZTK observations
On Sep 21, 2009, at 11:42 AM, Martijn Faassen wrote: > * zope.minmax: is this package being used? If not, we could consider > removing it from the ZTK. It's easy to find that it's used by zope.session. It is used for conflict resolution. Regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 12:31 PM, Hanno Schlichting wrote: > We are in the business of content management. The most valuable > information the system and the entire physical machine has is the > content in the system. You don't run web applications on any kind of > shared servers where the system has any more valuable data. > > A person who is allowed to steal or delete the entire content is > what I call trusted. The potential additional damage of that person > breaking out of the web application is a minor concern compared to > this. Allowing any kind of TTW development is always going to be an > explicit opt-in, but if you are willing to allow this, we won't try > to stop you with limited access anymore. So, it's quite black and white. I would argue that there are several classes of users. At least these: 1. Trusted users inside your organization that makes the software.The role they get through their credentials has highest trust level and they could be allowed to do the most TTW. 2. Trusted users inside your customer organization. Those are usually the techies in the customer organization who configure your software to run the way they want. The role they get through their credentials has some trust level. They can change certain things TTW. 3. Untrusted users in your customer organization. These users get a role through their credentials that allows them to configure the software parts, but cannot do any TTW changes. 4. Untrusted customers of your customer organization. Plain web users. They just view the content. The granularity levels can be even finer between 1, 2, and 3 above. This allows for various shades of grey. However, since anybody's credentials can be stolen, I do not want to allow rock changes and arbitrary imports even to the users in class 1 above. Because: 1. they have the highest trust level in that web app, but 2. they are just an ordinary user on a machine running that web app, and 3. there are people who have higher credentials on that machine -- sysadmins. That's why leaving zope.security safer by default is the right thing. If you want to allow more, wrap around it someorg.lesssecurity or even someorg.nosecurity. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] uuid.UUID as a rock in zope.security
On Apr 10, 2009, at 11:32 AM, Hanno Schlichting wrote: > We do have the use-case of allowing trusted people to add templates or > code TTW and many other things like data level and view based > security. > The RestrictedPython case however is something we will gladly give up. Trusted people!? Are you checking their ID at the door? All you have in terms of trust are their credentials. You don't want to allow many, many things TTW, even if they logged in with the trusted credentials. Otherwise, you give them the same credentials on your physical machine that serves that app (e.g. they import os TTW). Finally, even if you are fine with allowing that because you trust them, who guarantees that every login with those credentials is really that trusted person? Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.app.generations/trunk/src/zope/app/generations/README.txt made blocks consistent
> On Mon, Apr 6, 2009 at 11:47 AM, Baiju M wrote: >> >> Why we cannot use literal blocks for source code ? >>> From the above documentations, I can see that it works for doctest. >> And we have used it in many places. Also in PyPI >> (long_description), it looks better. Because reST specification says that they are not doctests any more if you use ::. They are literal blocks in that case. http://docutils.sourceforge.net/docs/ref/rst/restructuredtext.html#doctest-blocks Specifically the sentence: "If both are present, the literal block syntax takes priority over Doctest block syntax" ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.annotation/trunk/setup.py Whitespace fixes
On Apr 1, 2009, at 5:44 PM, Jacob Holm wrote: > If this whitespace fix is based on the current style guide, I think > the guide needs to be fixed. I find the fixed version much less > readable. A function that takes this many arguments should have an > exception to the PEP 8 rule of no whitespace around the equals sign > used for keyword arguments. I *think* a reasonable rule is that if > you split the call over multiple lines with one argument per line, > you should add single spaces before and after the equals sign. What > does anyone else think? -1 The PEP-8 and Zope style for keyword arguments work here just fine. Readability is improved by putting arguments on separate lines, not by adding space around equal sign. Additionally, we could do without fancy spacing. For example, the lists don't have a consistent style in this patch. One avoids fancy spacing ... >> +classifiers=[ >> 'Development Status :: 5 - Production/Stable', >> 'Intended Audience :: Developers', >> 'License :: OSI Approved :: Zope Public License', >> @@ -40,23 +40,23 @@ >> 'Topic :: Internet :: WWW/HTTP', >> 'Topic :: Software Development', >> ], The other two use fancy spacing, are not alphabetically sorted, and do not have consistent rule on commas after the last element ... >> +install_requires=['setuptools', >> + 'zope.interface', >> + 'zope.component', >> + 'zope.location', >> + 'zope.proxy', >> + ], >> +extras_require=dict( >> +test=['zope.testing', >> + 'ZODB3'], >> ), This would be more consistent, is sorted, and ensures easy addition/ removal of each line including the first, and the last line in the lists. install_requires=[ 'setuptools', 'zope.component', 'zope.interface', 'zope.location', 'zope.proxy', ], extras_require=dict( test=[ 'ZODB3', 'zope.testing', ], ), ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Namespace declaration using pkgutil vs pkg_resources
On Mar 11, 2009, at 10:29 AM, Martijn Faassen wrote: > Since Jim says you're not missing something, I'm going to add to the > Zope Framework Steering Group decisions that this is enough and we > could clean up __init__.py's to this if we would want to. So, let me try to understand the decision process here: 1. The extras_require is banned to enable building with regular distutils. 2. pkgutil is now banned which will prevent regular distutils from working properly. What exactly do we want to achieve? Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] setup.py "extra" dependencies
On Mar 5, 2009, at 5:02 PM, Laurence Rowe wrote: > Gary Poster wrote: >> I disagree with the blanket statement. >> >> I do lean towards not having the extras for the test package only. >> I'm fine with the policy "If you want zope.testing for your tests, >> then keep it as a dependency for the package". >> >> But I like to have the option of extras for testing additional >> setups. >> >> zc.async uses extras so that the main tests show the functionality as >> a Python library; another level adds more Zope dependencies, with >> associated tests; and the last level adds the most. I could have >> divided these up into multiple teensy-weensy packages but I didn't >> really want to. It seemed like overkill. >> ... >> > It seems there is a 'tests_require' > """ > If your project's tests need one or more additional packages besides > those needed to install it, you can use this option to specify them. > It should be a string or list of strings specifying what other > distributions need to be present for the package's tests to run. When > you run the test command, setuptools will attempt to obtain these > (even going so far as to download them using EasyInstall). Note that > these required projects will not be installed on the system where > the tests are run, but only downloaded to the project's setup > directory if they're not already installed locally. > """ Thanks for trying to help, but "tests_require" will not help here. When Gary wrote zc.async, he went to a great length to document it and make it useful for a wide variety of use cases. http://packages.python.org/zc.async/1.5.0/ There are three different zc.async configurations. 1. minimal 2. more 3. everything Each of the use cases above requires the packages for _both_ runtime and tests. The only way to provide all three options to developers is using extras. Which zc.async configuration you will actually use in your application depends on your needs and your application setup. For example, if you list "zc.async [z3]" you'll get the option 3 above. See the docs for zc.async for details, please. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: z3c.mimetype/ Create infrastructure for z3c.mimetype
On Feb 24, 2009, at 8:53 AM, Dan Korostelev wrote:
> 2009/2/24 Benji York:
>> On Tue, Feb 24, 2009 at 8:29 AM, Dan Korostelev wrote:
>>> Heh, nice trick with `z` :) Thank you.
>>
>> A slight refinement:
>>
>>svn mkdir path-to-repo/new-project{,trunk,tags,branches}
>>
>> Using the `z` trick, that would be:
>>
>>svn mkdir `z`/new-project{,trunk,tags,branches}
>
> Thanks! BTW, there tips are probably useful enough to be included to
> zope3docs' development section. :)
Or even one character shorter, (plus no need to create a script, put
it in the path and make it executable)
:-)
svn mkdir $Z/new-project{,trunk,tags,branches}
where Z is an environment variable in your .profile (or .bash_profile)
Z=svn+ssh://svn.zope.org/repos/main
export Z
or .login for C shell users
setenv Z svn+ssh://svn.zope.org/repos/main
Do we need to put a disclaimer that for the shortcut shown above the
shell needs to support brace expansion -- the output of ``set -o``
should have ``braceexpand on``.
Most of the modern Bourne-derived shells do have it and it's on by
default. The C shell has always had it AFAIK. A user could switch it
off in both shell kinds.
I guess that would be too much detail.
:-)
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
On Feb 19, 2009, at 12:43 PM, Tres Seaver wrote:
>> Exactly . As I mentioned in the previous post, sorting is the *key*
>> here. [Pun intended].
>> Grouping (python, zope., myapp. modules order), or non-grouping,
>> becomes a non-issue when imports are sorted.
>>
>> +1
>
> - -1. I prefer the PEP8 grouping, where "stdlib" imports are
> separated
> from "dependecy" imports, which are separated from "local" imports.
> Note that this is *not* subjective (an import is unambiguously in
> exaclty one of those three classifications.)
If you read my previous post, you'll see that I also prefer PEP-8 style.
http://mail.zope.org/pipermail/zope-dev/2009-February/034629.html
What I argued and gave +1 for is that *sorting* is the most important
requirement. I explained the details in the previous post.
> - -1, especially in heavily-namespaced libraries: I vastly prefer from
> imports to the noise of repeating the module path everywhere. A one
> chearacter search ('*' or '#') normally finds the import for me, which
> makes the repetition useless.
By the character mentioned it seems you use Vim.
Arguably, one can use another key press in Vim for name completion
during typing. :-)
Seeing where the name comes from during the code review (or when
reading a diff), without having to press that key is important to some
people.
Personally, I am used to finding such things in an editor using tags,
because, for example, in C programming, one cannot use namespace
qualifiers anyway and the names can come from any other file in a
large project.
Such topics are obviously too subjective and sometimes defended too
passionately. I _tried_ to argue in my original post linked above
that such discussions are not productive. I can adapt to any style
and believe that the fine grain details should not be dogmatically
enforced but rather allow for variations in such subjective preferences.
Best regards,
Zvezdan
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
On Feb 19, 2009, at 11:03 AM, Jim Fulton wrote: > I sort my imports. Period. This makes from imports come before > regular imports (because f comes before i). I discourage from > imports, so this isn't much of an issue for me except for old code. > Having imports sorted takes very little effort and makes imports > easier to find and duplicated easier to spot. Grouping imports makes > imports harder to maintain and read, especially since groupings are > arbitrary unless they follow package boundaries, and just sorting > imports groups imports by package boundaries. Exactly . As I mentioned in the previous post, sorting is the *key* here. [Pun intended]. Grouping (python, zope., myapp. modules order), or non-grouping, becomes a non-issue when imports are sorted. +1 > BTW, I strongly discourage from imports. (I didn't always have this > opinion, but have seen the error of my ways. Thanks to Fred Drake for > nudging me in this direction.) IMO, this is wildly more important than > any of the issues raised in this thread. Very important for code maintenance/readability! +1 Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
> Which attribute naming is current? > == > > Do we use under_scores or mixedCaseNames? > > I think I remember that we decided to follow PEP 8 for new code and > invoke the "local consistentency" rule on old code. Is that correct? According to this document in Zope3 developer info (http://wiki.zope.org/zope3/DeveloperInfo ) it is. http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt However, it seems not everybody agrees with that document completely. :-) > Import ordering > === > > Jim proposed an alternative rule for ordering imports. Is this > official? > > (My vote is +1 on it) I like PEP-8 rule with alphabetically sorted groups. import some-python-module ... import zope.some-module ... import myapp.some-module ... It's consistent with similar import/include rules for other languages and large projects. For example, type "man style" on a Mac or BSD computer for BSD kernel style guide. Having said the above, I personally don't think any of the points above are so much important. For example, a single group of sorted imports (which is I think what you refer to) will still form sub-groups internally because of sorting (only without empty lines in between). The one interesting difference is that z3c.something or zc.something will sort before zope.something. Since z3c.something almost certainly depends on zope.something that looks a little out of order. Still, I don't think it's worth arguing over that difference. Similarly both method_name() and methodName() look fine to me. One could argue that mixedCase() makes public attributes visually distinct from local variables (as is suggested in http://wiki.zope.org/zope3/ZopePythonNamingConventions) . So, deviating from PEP-8 in that regard doesn't bother me at all. OTOH, there's a simplicity in following the PEP-8 single rule for any variable/attribute. Consistency is good on a coarse grain level, but once we start going into fine grain details -- whether there's a blank line in between sorted import groups or not -- it becomes unproductive. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Coding style clarifications
On Feb 19, 2009, at 5:13 AM, Wichert Akkerman wrote: > Previously Christian Theune wrote: >> Which attribute naming is current? >> == >> >> Do we use under_scores or mixedCaseNames? >> >> I think I remember that we decided to follow PEP 8 for new code and >> invoke the "local consistentency" rule on old code. Is that correct? > > That would make the end result inconsistent. I seem to remember > camel case being declared 'the zope standard'. You probably remember right for some point in time at least. However, see the discussion from last year, started by this message. http://mail.zope.org/pipermail/zope3-dev/2007-August/023394.html and the decision that was apparently adopted is in this document (section titled "Coding style"): http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope] Zope 3.4.0 Released!
On Feb 2, 2009, at 9:28 AM, Sebastien Douche wrote: > KGS 1.x uses new anatomy (major/minor/): > http://download.zope.org/zope3.4/intro.html Am I the only one who finds those pale green links on a white background quite unreadable? The code examples with that same color on dark grey are OK, but such a pale color on white just doesn't work. At least for me. Regards, Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zc.sourcefactory/trunk/buildout.cfg color by default
On Dec 8, 2008, at 10:56 AM, Benji York wrote: > On Mon, Dec 8, 2008 at 2:22 AM, Michael Howitz <[EMAIL PROTECTED]> wrote: >> Log message for revision 93766: >> color by default > > This setting apparently causes problems for people who use Emacs, so > for zope. and zc. packages at least, we don't use --auto-color. That argument is really lame. Should we now go back to VT100 terminals because _some_ Emacs users are annoyed that ANSI colors break their shell window display? They should read about ansi-color-for-comint-mode-on and add-hook. There are probably other ways to do this. It is equally annoying when _some_ Emacs users leave lines filled with nothing but spaces all over the Zope code base. Yet, nobody asked for a rule that would somehow prevent that. The Emacs users can easily prevent these spaces by setting show-trailing-whitespace in python-mode-hook or simply using delete-trailing-whitespace from time to time. Setting next-line-add-newlines to nil in the .emacs file is also a good idea. Anyway, why enforce an ancient terminal style on all of us when Emacs users could actually set their shell window style? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.sendmail fails on windows
On Nov 1, 2008, at 3:56 PM, Adam GROSZER wrote: > Hello Benji, > > Seems like your r80928 breaks windows compatibility, because it does > not support os.link and os.unlink. FWIW, os.unlink _is_ supported on Windows. It's identical to os.remove. However, os.link is Unix specific and should be addressed. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZopePublication Competing writes/reads
On Oct 23, 2008, at 5:27 AM, Hermann Himmelbauer wrote: > Am Mittwoch 22 Oktober 2008 16:44:58 schrieb Satchidanand Haridas: >> What version of zope.session are you using? >> >> A fix (using zope.minmax) for ConflictErrors related to the update of >> access time on sessionData object was committed into zope.session in >> rev76899. Not sure if that solves this problem of conflict errors >> that >> you see, but if you are using a version of zope.session prior to >> r76899, upgrading may make those problems go away. > > Hmmm, I'm using zope.session from the KGS, so I'm unsure which > revision I have. However, when looking at the "$Id:" lines in the > python files, I can see e.g. the following line: > > tests.py:$Id: tests.py 80055 2007-09-25 21:28:54Z rogerineichen > > That probably indicates, that my revision > r76899, is that true? Yes you have higher revision. However, there was another issue that was fixed in -r 87351. The following line should be there: $Id: tests.py 87351 2008-06-12 21:02:43Z gary $ That version was released immediately in -r 87352 as zope.session-3.5.2 and the change log states: version 3.5.2 (2008-06-12) -- - Remove ConflictErrors caused on SessionData caused by setting ``lastAccessTime``. Using zope.session-3.5.2 is worth the try. Zvezdan ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] zope.app.container won't compile
On Oct 20, 2008, at 9:45 AM, Tres Seaver wrote: > Did you look at the include' directories? > > $ svn propget svn:externals $ZSVN/zope.app.container/tags/3.5.6/ > include > persistent svn://svn.zope.org/repos/main/ZODB/trunk/src/ > persistent > zope.proxy \ > svn://svn.zope.org/repos/main/zope.proxy/trunk/src/zope/proxy > > $ svn propget svn:externals $ZSVN/zope.app.container/tags/3.6.1/ > include > persistent -r 71248 \ > svn://svn.zope.org/repos/main/ZODB/branches/3.7/src/persistent > zope.proxy \ > svn://svn.zope.org/repos/main/zope.proxy/trunk/src/zope/proxy FWIW, the external was changed for zope.app.container-3.5.6. When KGS 3.4.0c5 was replaced with 3.4.0c6 somebody has removed all other versions of zope.app.container from KGS and stored only zope.app.container-3.5.6 there. (Was that necessary?) In KGS 3.4.0c5 there were several versions of zope.app.container with 3.5.3 being the highest version number. The diff between zope.app.container-3.5.3 and 3.5.6 starts like this: = >8 = Property changes on: include ___ Name: svn:externals - persistent -r 71248 svn://svn.zope.org/repos/main/ZODB/ branches/3.7/src/persistent zope.proxy svn://svn.zope.org/repos/main/zope.proxy/trunk/ src/zope/proxy + persistent svn://svn.zope.org/repos/main/ZODB/trunk/src/ persistent zope.proxy svn://svn.zope.org/repos/main/zope.proxy/trunk/src/ zope/proxy = 8< = So, the change was introduced then, and reverted now for 3.6.1. > Two observations: > > - - No released version should have 'trunk' externals for anything. +1 > - - The 3.5.6 version is pulling in a 'cPersistence.h' which has a > '#include "py24compat.h"' in it. > >> Of course, if everybody's just annoyed and wants to move on, I'll be >> happy to create another 3.6.2 release with Sidnei's fix in it. > > We should fix the externals for both 3.5.x and 3.6.x and re-release > both. +1 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.sendmail/trunk/src/zope/sendmail/mailer.py try again with catching sslerror, thx Jens
On Oct 5, 2008, at 4:51 AM, Adam Groszer wrote: > connection.sendmail(fromaddr, toaddrs, message) > try: > connection.quit() > -except: > +except socket.sslerror: > +#something weird happened while quiting > pass This is better because it catches a _specific_ exception. However, are we _certain_ that the socket is closed after this? If not, I think we should close it explicitly instead of passing on it. Thoughts, comments, anybody? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Checkins] SVN: zope.sendmail/trunk/src/zope/sendmail/mailer.py gmail seems to burp nowadays on smtp quit, deep down in smtplib
On Oct 5, 2008, at 1:57 AM, Adam Groszer wrote: > Log message for revision 91759: > gmail seems to burp nowadays on smtp quit, deep down in smtplib > mail should be safely sent at this point "... deep down ... should be ..." These words do not sound very encouraging. > connection.sendmail(fromaddr, toaddrs, message) > -connection.quit() > +try: > +connection.quit() > +except: > +pass The purpose of quit() is unrelated to whether the mail was or was not sent. The purpose is to gracefully send a QUIT to SMTP server and then _close_ the socket. Are we absolutely sure that the socket gets closed here and that we are not leaking sockets (i.e., file handles) here? If we are not, we should not pass on the exception. Moreover, we should not pass on _every_ exception. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] permission inheritance from conflicting groups
On Jun 9, 2008, at 9:38 PM, Daniel Blackburn wrote: It seems that there either may be an issue with Zope security or I do not understand it properly. Please let me know what you guys think. It seems you misunderstood it. Lets say we have a principal with no direct permissions or roles assigned to see a view index.html. The principal has two groups, group1 and group2. group1 allows the principal to see index.html and group2 denys access to index.html. It seems to me that in this situation of conflicting permissions a deny permission should result for the principal to the index view. However it does not, the permission will be digested into allowing the principal to have access to the view. Is this the desired behavior, or just simply overlooked. I looked in the doctests and did not see anything like this. Any feedback would be appreciated. Here's a scenario from the real world. You start working in a company. The security team puts you in a group of regular employees so that when you swipe you card at the card readers in front of each door you are allowed to rooms A, B, and C, but explicitly denied access to rooms D, E, and F. After a while you are promoted to a special team. The security team adds you to that group. Now when you swipe your card at the door D, the computer checks the following. - Read your employee ID from the card. - Get the groups that employee ID belongs to. - Regular employee group - Cannot access door D - Special team group - Can access door D - Employee ID belongs to at least one group that can access this door. - Open the door. The door F will be open only to a member of the security team (group). This is equivalent to the old times when they give you a key when you start working. That key does not let you in all rooms. After a while, you are promoted, which really means that you are in a special group. They give you another key. That one lets you in one more room. Can you access that room? Not with the first key. How about the second? ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: AW: [Zope-dev] Re: [Zope3-Users] How do I automatically login a user
On Apr 9, 2008, at 5:07 AM, kevin gill wrote: 1. IP Extraction Extract the IP Address from the credentials and store it. Return the IP Address in the dictionary from extractCredentials(). The value from request._environ['HTTP_X_FORWARDED_FOR'] will be used if present. otherwise request._environ['REMOTE_ADDR']. On a basis of "privacy" of attributes starting with underscore, such as _environ, I would suggest using request.headers (for X-Forwarded- For) and request.environment instead. These are defined in the public interface API. -- Zvezdan Petkovic <[EMAIL PROTECTED]> ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3.4 Release and KGS
On Jan 25, 2008, at 8:56 AM, Christophe Combelles wrote: Zvezdan Petkovic a écrit : On Jan 24, 2008, at 9:16 PM, Stephan Richter wrote: Before I am going to start that process, I wanted to ask whether people would like to see any new packages in the KGS or whether there are new releases of packages that need to be updated. How about using zc.buildout-1.0.0 instead of zc.buildout-1.0.0b31 in the KGS? buildout 1.0 is already included, but zodb 3.8.0 not yet http://svn.zope.org/zope.release/branches/3.4/controlled-packages.cfg?view=markup How about including it in the index? See here: http://download.zope.org/zope3.4/zc.buildout/ so that it can be used in the buildout configuration [buildout] index = http://download.zope.org/zope3.4/ -- Zvezdan Petkovic <[EMAIL PROTECTED]> ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Zope 3.4 Release and KGS
On Jan 24, 2008, at 9:16 PM, Stephan Richter wrote: Before I am going to start that process, I wanted to ask whether people would like to see any new packages in the KGS or whether there are new releases of packages that need to be updated. How about using zc.buildout-1.0.0 instead of zc.buildout-1.0.0b31 in the KGS? -- Zvezdan Petkovic <[EMAIL PROTECTED]> ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
