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. Agreed. 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. :-) -- smk
