[Zope-PAS] Re: Test layers for pastc
Tres Seaver <[EMAIL PROTECTED]> writes: > Ross Patterson wrote: > >> I'd love to convert PAS's tests to layers for test setUp and tearDown. >> Any objections? > > Layers are all about sharing setup across a set of tests, which means > they risk breaking test isolation. I normally don't use layers for > anything which is a pure "unit test," but can see the point for > "function" or "integration" tests. > > Are there a specific set of tests you have in mind which have > significant setup / teardown costs? Well I also find that layers make factoring and re-using setup much easier, so that was my motivation. If that's an abuse of the intentions of layers, then nevermind. :) Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Test layers for pastc
I'd love to convert PAS's tests to layers for test setUp and tearDown. Any objections? Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: [Plone-developers] Getting PAS users to show up in the access log/Z2.log
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Ross Patterson wrote: >> Wichert Akkerman <[EMAIL PROTECTED]> >> writes: >> >> > Previously Ross Patterson wrote: >> >> Ross Patterson <[EMAIL PROTECTED]> writes: >> >> >> >> > It seems like ZServer/medusa/http_server.py is responsible for logging >> >> > requests to the access log/Z2.log and it only extracts the user from the >> >> > HTTP basic auth header. >> >> > >> >> > I'd like to have the Z2.log reflect my PAS users so I started a branch >> >> > at >> >> > http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/ that >> >> > hacks some request data. You can see the meat of it in the following >> >> > changeset: >> >> > >> >> > http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/PluggableAuthService.py?view=diff&r1=79171&r2=79170> >> >> > > >> >> > I'm sure this is just about the worst way to do this. :) I just wanted >> >> > to get the discussion started. >> >> > >> >> > I suspect that ZServer/medusa/http_server.py is only invoved for certain >> >> > Zope setups and that other Zope setups (twisted, etc.?) might log >> >> > differently. >> >> > >> >> > So what would be a better way to approach this? Does anyone else have a >> >> > solution to this problem? >> >> >> >> I forgot to mention that one of my goals is to have this behavior be PAS >> >> pluggable. In particular, it seems obvious that user.getUserName() >> >> should be the default that's used, but I have a need to use something >> >> else, so I'd like to be able to write a plugin that does this. >> > >> > I suspect that instead of doing yet another PAS plugin it would be more >> > useful to make the zserver logging modular. >> >> I don't suppose you could provide any suggestions for a direction for >> this? I really know very little about the zserver. > > Perhaps it would be interesting to see if the standard python logging > module can be used to log requests as well. Yeah, I was thinking about that. If it were so, then at least I'd have one way to modify the behavior more modularly. One thing I can't quite think my way out of is that the logging is done in the response._finish() in ZServer/PubCore/ZServerPublisher.py::27(__init__). The problem is this happens well after a bunch of other tear down has already completed, such as resetting the SecurityManager. Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: [Plone-developers] Getting PAS users to show up in the access log/Z2.log
Wichert Akkerman <[EMAIL PROTECTED]> writes: > Previously Ross Patterson wrote: >> Ross Patterson <[EMAIL PROTECTED]> writes: >> >> > It seems like ZServer/medusa/http_server.py is responsible for logging >> > requests to the access log/Z2.log and it only extracts the user from the >> > HTTP basic auth header. >> > >> > I'd like to have the Z2.log reflect my PAS users so I started a branch at >> > http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/ that >> > hacks some request data. You can see the meat of it in the following >> > changeset: >> > >> > http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/PluggableAuthService.py?view=diff&r1=79171&r2=79170> >> > > >> > I'm sure this is just about the worst way to do this. :) I just wanted >> > to get the discussion started. >> > >> > I suspect that ZServer/medusa/http_server.py is only invoved for certain >> > Zope setups and that other Zope setups (twisted, etc.?) might log >> > differently. >> > >> > So what would be a better way to approach this? Does anyone else have a >> > solution to this problem? >> >> I forgot to mention that one of my goals is to have this behavior be PAS >> pluggable. In particular, it seems obvious that user.getUserName() >> should be the default that's used, but I have a need to use something >> else, so I'd like to be able to write a plugin that does this. > > I suspect that instead of doing yet another PAS plugin it would be more > useful to make the zserver logging modular. I don't suppose you could provide any suggestions for a direction for this? I really know very little about the zserver. Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: Getting PAS users to show up in the access log/Z2.log
Ross Patterson <[EMAIL PROTECTED]> writes: > It seems like ZServer/medusa/http_server.py is responsible for logging > requests to the access log/Z2.log and it only extracts the user from the > HTTP basic auth header. > > I'd like to have the Z2.log reflect my PAS users so I started a branch at > http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/ that > hacks some request data. You can see the meat of it in the following > changeset: > > http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/PluggableAuthService.py?view=diff&r1=79171&r2=79170 > > I'm sure this is just about the worst way to do this. :) I just wanted > to get the discussion started. > > I suspect that ZServer/medusa/http_server.py is only invoved for certain > Zope setups and that other Zope setups (twisted, etc.?) might log > differently. > > So what would be a better way to approach this? Does anyone else have a > solution to this problem? I forgot to mention that one of my goals is to have this behavior be PAS pluggable. In particular, it seems obvious that user.getUserName() should be the default that's used, but I have a need to use something else, so I'd like to be able to write a plugin that does this. Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Getting PAS users to show up in the access log/Z2.log
It seems like ZServer/medusa/http_server.py is responsible for logging requests to the access log/Z2.log and it only extracts the user from the HTTP basic auth header. I'd like to have the Z2.log reflect my PAS users so I started a branch at http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/ that hacks some request data. You can see the meat of it in the following changeset: http://svn.zope.org/PluggableAuthService/branches/rossp-access-log/PluggableAuthService.py?view=diff&r1=79171&r2=79170 I'm sure this is just about the worst way to do this. :) I just wanted to get the discussion started. I suspect that ZServer/medusa/http_server.py is only invoved for certain Zope setups and that other Zope setups (twisted, etc.?) might log differently. So what would be a better way to approach this? Does anyone else have a solution to this problem? Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: Duplicate pulgin types created by PluginRegistry.exportimport._updatePluginRegistry
Tres Seaver <[EMAIL PROTECTED]> writes: > $ find structure/acl_users > structure/acl_users > structure/acl_users/.objects > structure/acl_users/pluginregistry.xml > structure/acl_users/chooser.xml > structure/acl_users/sniffer.xml > structure/acl_users/credentials_cookie_auth.xml > structure/acl_users/credentials_basic_auth.xml > structure/acl_users/source_users.xml > structure/acl_users/portal_role_manager.xml > structure/acl_users/local_roles.xml > structure/acl_users/source_groups.xml Thanks! That's all I needed. Please disregard. > However, still don't see why your overrides.zcml registers the handler > for the IPluginRegistry. Including your export / import handers as I still need to make sure that my patched version the IPluginRegistry setup adapter is used to address the problem with duplicates. At least until (if?) my patch gets applied. Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: Duplicate pulgin types created by PluginRegistry.exportimport._updatePluginRegistry
Tres Seaver <[EMAIL PROTECTED]> writes: > Ross Patterson wrote: >> Tres Seaver <[EMAIL PROTECTED]> writes: >> >>> Thanks! Can you please add to the PAS collector so we don't lose the patch: >>> >>> http://www.zope.org/Collectors/PAS >> >> Will do. >> >>> I don't understand the need for this handler, or why your overrides.zcml >>> uses it for IPluginRegistry. The "normal" handers for PAS plugins are >>> all in PAS itself, and the "normal" one for the registry is in >>> PluginRegsitry. >> >> As I understand it, the PAS setup handlers expect the setup tool to be >> located *inside* the acl_users folder. I taks this from the fact that >> the setup handlers get the adapter that does the actual importing and >> exporting with an adapter for context.getSite(). >> >> I wanted to be able to do PAS configuration in a setuphandler executed >> inside a setup tool for a CMF *portal* for the acl_users folder >> *subobject* of that portal. As such I adapt >> getToolByName(context.getSite(), 'acl_users'). >> >> Is this incorrect? > > Hmm, I guess I normally just have the PAS dumped as part of the > "structure" of the site, where the normal handlers get used on the PAS > as a subobject. > > If you want the PAS to go into a different part of the profile, then the > "structure" dump needs to exclude it, and your handlers would work fine. > However, still don't see why your overrides.zcml registers the handler > for the IPluginRegistry. Including your export / import handers as > steps should do the trick, without the funky override. Just to make sure I'm hearing this correctly, you'd put it in something like profile/default/structure/acl_users/pluginregistry.xml? Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Re: Duplicate pulgin types created by PluginRegistry.exportimport._updatePluginRegistry
Tres Seaver <[EMAIL PROTECTED]> writes: > Thanks! Can you please add to the PAS collector so we don't lose the patch: > > http://www.zope.org/Collectors/PAS Will do. > I don't understand the need for this handler, or why your overrides.zcml > uses it for IPluginRegistry. The "normal" handers for PAS plugins are > all in PAS itself, and the "normal" one for the registry is in > PluginRegsitry. As I understand it, the PAS setup handlers expect the setup tool to be located *inside* the acl_users folder. I taks this from the fact that the setup handlers get the adapter that does the actual importing and exporting with an adapter for context.getSite(). I wanted to be able to do PAS configuration in a setuphandler executed inside a setup tool for a CMF *portal* for the acl_users folder *subobject* of that portal. As such I adapt getToolByName(context.getSite(), 'acl_users'). Is this incorrect? Ross ___ Zope-PAS mailing list Zope-PAS@zope.org http://mail.zope.org/mailman/listinfo/zope-pas
[Zope-PAS] Duplicate pulgin types created by PluginRegistry.exportimport._updatePluginRegistry
I recently wired together the GenericSetup handlers from PAS in an
extension profile for another product. This way I can support fully
declaritive import/export steps for setting up a PAS user folder
within a CMF GS profile using the PAS subdirectory. As such we can
avoid the declaritive abuse of GS used in borg, membrane, remember,
etc..
It all worked great with a minimum of code in the other product with
one exception. If a plugin type and active plugins for that type have
been configured previously (whether by a GS profile or not) then
registering the plugin type again with a new list of active plugins
will result in duplicates in registry._plugin_types (as in
acl_users.plugins._plugin_types). This doesn't actually break any
functionality but results in duplicates in the PAS ZMI.
Attached is a small patch that avoids this rather simply. I'd love to
see it merged so I don't have to maintain changed copies in my own
product to have extension profiles that modify a PAS UF configuration.
Index: exportimport.py
===
--- exportimport.py (revision 71599)
+++ exportimport.py (working copy)
@@ -81,7 +81,9 @@
for info in reg_info['plugin_types']:
iface = _resolveDottedName(info['interface'])
-registry._plugin_types.append(iface)
+# Avoid duplicate plugin types
+if iface not in registry._plugin_types:
+registry._plugin_types.append(iface)
registry._plugin_type_info[iface] = {'id': info['id'],
'title': info['title'],
'description': info['description'],
I've also attached the module within my product's exportimport package
and the overrides.zcml used in case this is of interest to anyone.
"""GenericSetup export/import handlers for setting up
PluggableAuthService plugins in acl_users."""
from StringIO import StringIO
from Persistence import PersistentMapping
from Products.GenericSetup.interfaces import IFilesystemImporter
from Products.GenericSetup.interfaces import IFilesystemExporter
from Products.GenericSetup.utils import _resolveDottedName
from Products.GenericSetup.content import FauxDAVRequest
from Products.GenericSetup.content import FauxDAVResponse
from Products.PluginRegistry.exportimport import PluginRegistryFileExportImportAdapter as Base
from Products.PluginRegistry.exportimport import PluginRegistryImporter
from Products.PluginRegistry.exportimport import _FILENAME
from Products.CMFCore.utils import getToolByName
# TODO: Wire up importers that don't remove objects not specified in
# either .preserve or .objects
def importPAS(context):
"""Import and setup any PAS plugins."""
uf = getToolByName(context.getSite(), 'acl_users')
IFilesystemImporter(uf).import_(context, 'PAS', True)
def exportPAS(context):
"""Export any PAS plugins with configurations."""
uf = getToolByName(context.getSite(), 'acl_users')
IFilesystemExporter(uf).export(context, 'PAS', True)
overrides.zcml
Description: Binary data
Ross
___
Zope-PAS mailing list
Zope-PAS@zope.org
http://mail.zope.org/mailman/listinfo/zope-pas
