Dnia 2014-08-14, czw o godzinie 04:27 +0000, Shawn Debnath pisze:
> - Build a hash table of relevant data and store it in the authreg_t
>   private data member.

Agreed, that needed internal bookkeeping makes it not feasible.

> - Retrofit existing interfaces with the necessary data.
>   a. Introduce void *sess_private in sess_t.

It's not really sess_private, but authreg_private, right?

>   int (*create_challenge)(authreg_t ar, sess_private *data,
>     const char *username, const char *realm, const char *challenge,
>     int maxlen);
>   int (*check_response)(authreg_t ar, sess_private *data,
>     const char *username, const char *realm, const char *resource,
>      const char *challenge, const char *response);
>   Pros: Maintain same methods but new parameters, faster approach.
>   Cons: (BIG)breaks everyone out there. In some cases, other 3rd parties
>     may want similar mechanism for plain text login as well and this
>     approach wouldn't work for them.

I think we should extend all authreg calls with a pointer to session
attached, authreg private data.
In the simplest case it could be even set to point to sess_st, for the
mechanizm to dig in session by itself.
This is how it is done all around jabberd2.

Also good point, that create_challenge misses realm parameter.

If we go for it, we will just release 2.4.x line which hints API
breakage. ;-)

>   /* Extension for custom authentication providers */
>   int (*custom_auth_get)(authreg_t ar, authdata_t data);
>   int (*custom_auth_set)(authreg_t ar, authdata_t data);

I don't like this approach for two reasons.
- custom_auth does not really mean anything. as it is now it is clean -
either we have password verification, or challenge/response.
- custom_auth is used in "ar_mechs & AR_MECH_TRAD_CRAMMD5", so it is not
really custom, but CRAM-MD5, right?

Let's just implement CRAM-MD5 properly, with all needed features, even
if it means API changes.
We're open source - we are not afraid to change things. :-)


Reply via email to