Hi - >-- Original Message -- >Reply-To: [EMAIL PROTECTED] >Date: Tue, 27 Aug 2002 09:51:09 -0700 >From: Justin Erenkrantz <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Re: authentication rewrite > > >On Tue, Aug 27, 2002 at 10:12:43AM -0400, [EMAIL PROTECTED] wrote: >Without seeing use cases, it's hard to know what people want. For >now, I can only go off of what we have now. > >(I'm hoping that people who write third-party auth engines speak >up now and point out how this API could make it better for them if >it only did XYZ.)
welp, that is why i spoke up i suppose. A use case is the desire for ldap auth to allow for property requirements. e.g. Require ldap_prop department=engineering for example (that's hypothetical syntax). You would need to add a new function to the callback structure validate_property(name, value) or something. While this would be easy to add (and would be reusable by various database auth modules) - it is just an example of many possible requirements. you could add another callback function to your backend structure - this function would be register_requirement_handler(requirement_name, function). In your switch statement "valid-user", "user", "group", it could fall through by looking for a handler that has been registered for that requirement. That handler would simply be passed the rest of the requirement string - and would return 0,1. I could send a patch to your current code if that would be clearer - its really pretty simple, but would allow the backends to get at least a little more powerful (and would solve the ldap_prop case i illustrated above sterling
