Hi, The various plugins interfaces references are hardcoded in most PAS/PlonePas API services. So adding the support of a new plugin interface qill require to subclass or monkey patch PAS or PlonePAS (depending on what API you need to change).
Perhaps I'm wrong or I didn't understand your issue, but wouldn't it be easier and safer to subclass or monkey patch the PloneLDAP plugins to limit the number of results of users enumeration ? Cheers -- Gilles Lenfant 2013/11/18 Sean Upton <[email protected]> > Hey folks, > > I want to be able to implement a custom PAS plugin type -- for user > enumeration by add-ons, not by Plone's core. I want to subclass > IUserEnumerationPlugin and use the subclass as a distinct key (e.g. > acl_users.listPlugins(IMyLimitedDirectoryEnumerationPlugin). > > While it is easy to create and register custom plugins, registering > custom plugin types seems more difficult, due to lack of public > interfaces in PluginRegistry and a global hardcoded _PLUGIN_TYPE_INFO > tuple in PAS. > > My use case is a very large LDAP directory (100k+ users) I want to > incidentally search in my add-ons (event invitations, finding users to > register into group collaboration system); I do not want to enable > search/enumeration in Plone's core user management (this directory > would only be used for authentication and user properties, otherwise). > > Is it reasonable to monkey-patch > Products.PluggableAuthService.PluggableAuthService._PLUGIN_TYPE_INFO > and modify acl_users.plugins._plugin_types and > acl_users.plugins._plugin_type_info in a migration to accomplish my > goal of having a custom plugin type? Is there a better solution that > I am just not seeing? > > Sean > _______________________________________________ > Product-Developers mailing list > [email protected] > https://lists.plone.org/mailman/listinfo/plone-product-developers > >
_______________________________________________ Product-Developers mailing list [email protected] https://lists.plone.org/mailman/listinfo/plone-product-developers
