authentication storage question

I'm in the middle of rewriting the client-side authentication system,
and people are right: it's much simpler and cleaner to have "RA pull
info from client when challenged", rather than "client preemptively
push data at RA". Many problems drop away, and code gets smaller.

I have one design problem, though.

Here's a typical code flow:

  1. client calls

      session_baton = RA->open (URL, vtable_of_callbacks)

  2. client calls

      RA->do_some_network_things (session_baton)
 

      * the RA layer is challenged by Apache

      * the RA layer uses the callback vtable to get information from
        the client. (the client has its own logic for getting info
        from argv[], or files, or user-prompts.)

      * authentication suceeds, so RA finishes its work. or
        authentication fails, and user sees immediate error.

  3. client repeats step 2 until finished, then calls

      RA->close (session_baton)

Here's the missing feature: if authentication was successful, it's
very likely that the auth info needs to be stored somewhere on the
client. (IOW, cached for next time. We're already doing this in our
current auth system.)

How does the client know if info needs to be stored? Or which info
needs to be stored?

- One possibility is that each RA->do_something() call return this
  information.

- Another possibility is that RA->close() is the only call to return
  this information.

- Another idea is to have RA do the auth storage itself, via another
  vtable callback. Each RA routine would have to remember to do this
  before returning.

Thoughts? I think the third idea is probably best.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006