On 24.6.2012, at 23.37, Jürgen Pabel wrote: > I am implementing a plugin (for the pop3/imap process) that requires > some data to provided from the authentication phase (a derivative of the > password). For that, I have now implemented a passdb plugin that > generates this data and I would like to "pass" this data down to the > mail process (pop3/imap) via extra_fields in the reply of the > authentication. The general idea is that my custom passdb plugin > calculates the data, sets the extra_field and returns some error > (authentication was not successful) so that the "real" passdb backend > can be invoked to "really" validate the authentication data.
This is a bit related to another feature people have requested: Ability to merge data from multiple userdbs into a single reply. Perhaps the same could be done for passdbs. Also in my TODO is that master=yes passdb currently preserves userdb extra fields, but not passdb extra fields and that behavior probably isn't optimal. There is already passdb { pass=yes } setting for masterdbs. I guess the same could be used for non-masterdbs and also added to userdbs. > However, in auth_request_handle_passdb_callback() the extra_fields are > reseted unless the return code is PASSDB_RESULT_USER_DISABLED. But if > that return code is used then any following passdb's aren't invoked any > more - which makes sense with respect to user authenticiation. I would > therefore like to propose that some IGNORE/CONTINUE-status to be > introduced in auth/passdb.h, that would be handled in that extra_fields > and possible other values are not reseted in order to allow such > propagation of data from authentication process down to the mail process > (which could be extracted from the reply string by parsing it). Yes, extra_fields really need to get reset between passdb calls. Same for userdb_reply. > As a further implementation alternative (to the parsing of the reply > string), I also propose that some new "environment" item be introduced > (in auth_request) in order to allow such data passing in a generic > manner. Maybe a new permanent_extra_fields, which gets added as default to new passdb/userdb lookups. If the lookup has pass=yes, the result gets added to permanent_extra_fields. Although the code is beginning to have too many extra_fields variables. Maybe it would be possible to merge extra_fields, extra_cache_fields and userdb_reply into one array of structs: struct auth_field { const char *key, *value; bool cache_only; bool userdb; bool permanent; }; > I hope you consider my proposal to be reasonable. If desired, I could > implement this myself and provide a patch for merging (based on 2.0.x). > If my proposal is generally unfavored, it would be great if any > alternative approaches for my situation were suggested. Thanks. I could add such a patch to v2.2.