I initially found issue #1710 a little daunting, and I think that's
mainly why it hasn't gotten three votes yet. But now that I
understand it, it makes good sense and I think it should go in, even
though it's kind of last-minute. Here is my attempt at explaining it:
Right now we pass the realm string to the first_credentials auth
callback, but not to next_credentials or save_credentials.
Presumably, the thinking was that you could always remember it in
first_credentials and use it later, right? Wrong. The providers
table can be viewed as a matrix, which might look like:
first_creds next_creds save_creds
Provider #1 <func> NULL NULL
Provider #2 <func> NULL <func>
The auth framework calls provider #1's first_credentials function,
succeeds, and then calls provider #2's save_credentials function. The
actual credentials are communicated through the shared "parameters"
hash, but the realm string is not robustly communicated at all.
Right now, our providers which implement save_credentials are simply
buggy; they store a realm string in the provider baton during
first_credentials and use it (without even checking) during
save_credentials.
Once you understand what's wrong, issue #1710 is a simple fix. It
would be *possible* to communicate the realm string through the
parameters array (thus avoiding an API change), but it would be better
to pass the realm string to next_credentials and save_credentials.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jan 22 04:51:41 2004