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
> /* 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. :-)