On 2012-06-24 4:37 PM, Jürgen Pabel juergen@pabel.net 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.

What specifically is the *purpose* of this?

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 think it is usually preferred that you do things like this against either the current shipping/stable branch (2.1.x), or even hg (2.2)... much better chance that it would be accepted.

--

Best regards,

Charles

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.