[Dovecot] Additional passdb result status

[Timo Sirainen]

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.