zope.app.security refactoring results
Hey there! The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: * zope.authentication - the most interesting and small. It contains the IAuthentication contract, as well as IUnauthenticatedPrincipal/IAuthenticatedGroup and company. Beyond that, it also contains several utilities related to principal lookup - the PrincipalLookupError and PrincipalSource/PrincipalTerms. * zope.principalregistry - it's an implementation of IAuthentication that's based on global non-persistent registry object. It provides zcml-based principal creation. Yes, it's the "global principal registry" from zope.app.security. * zope.localpermission - the implementation of persistent/local permission class that can be added and used per-site. It's a bit of (possibly deprecated) TTW development. I created another thread about possibility of death of local permisions, so may be this package will be named "zope.app.localpermission" and forgotten forever. :) Also, two other packages were touched: * zope.security - here migrated some bits of zope.app.security - the NoProxy definition for zope.i18nmessageid.Messages, the permission vocabularies, zcml definitions of some common permissions, like zope.View. * zope.publisher - here migrated the adapter from IPrincipal to ILoggingInfo and the adapters from zope.publisher's HTTP/FTP requests to ILoginPassword. May be they will be moved again, when we'll be doing zope.publisher's refactorings. One nice feature provided as a result of refactoring is possiblity of the authentication system to be used without of zope.publisher. The zope.app.authentication and z3c.authenticator probably can be modified/refactored not to depend on zope.publisher as well, but it will be another task. The original zope.app.security now only contains browser views and BBB imports. Other packages still need to be adapted to new imports, but I'd like to do that after releasing refactored packages. I already adapted zope.securitypolicy and zope.app.authentication though. It's a big win for zope.securitypolicy that it doesn't pull the whole zope anymore. Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) -- WBR, Dan Korostelev
2009/3/13 Dan Korostelev <nadako@gmail.com>:
The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: [snip] Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-)
BTW, now when we have a steering group, I'd like my changes to be approved by them :) -- WBR, Dan Korostelev
On Friday 13 March 2009, Dan Korostelev wrote:
2009/3/13 Dan Korostelev <nadako@gmail.com>:
The refactoring of zope.app.security is now generally done. In the process, three new packages has been created:
[snip]
Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-)
BTW, now when we have a steering group, I'd like my changes to be approved by them :)
You can assume I approve unless I send you a message. :-) Keep sending the summary E-mails as they are a good redux as well. Thanks for all your work! Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter wrote:
On Friday 13 March 2009, Dan Korostelev wrote:
2009/3/13 Dan Korostelev <nadako@gmail.com>:
The refactoring of zope.app.security is now generally done. In the process, three new packages has been created: [snip]
Please, check it out and say your opinion. I'd like new packages to be released ASAP. :-) BTW, now when we have a steering group, I'd like my changes to be approved by them :)
You can assume I approve unless I send you a message. :-) Keep sending the summary E-mails as they are a good redux as well.
Yeah, I think the rule for larger projects should be: * make sure at least one steering group member is involved in discussing your proposal. (I was, so that's fine) * assume the steering group approves unless informed otherwise. I'll make a note of the "make sure at least one steering group member is involved" bit in our decision making documentation. Regards, Martijn
Hey Dan, Thanks for doing the great work and thanks for this summary. Go Dan!! Could you update our upgrade_notes in the Zope Framework documentation with a sketch of your work here? My work is that eventually we can aggregate information from our changelogs to create a similar document from them, but we're not there yet. On a related note: I noticed that you earlier released some packages as a bugfix release even though they had been undergoing some dependency refactoring. I think we want to err on the side of caution an always do a feature release (x.y instead of x.y.z). I've noted this down now in the steering group decisions. Dan Korostelev wrote: [snip]
I created another thread about possibility of death of local permisions, so may be this package will be named "zope.app.localpermission" and forgotten forever. :)
+1, as mentioned in that thread. Regards, Martijn
On Monday 16 March 2009, Martijn Faassen wrote:
On a related note: I noticed that you earlier released some packages as a bugfix release even though they had been undergoing some dependency refactoring. I think we want to err on the side of caution an always do a feature release (x.y instead of x.y.z). I've noted this down now in the steering group decisions.
+1 Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
participants (3)
-
Dan Korostelev -
Martijn Faassen -
Stephan Richter