Sumit Bose <sbose(a)redhat.com> wrote
Fri, 18 Mar 2011 12:56:35 +0100:
| Also having an event loop would be only the first step. The internal
| preauthentication API needs to be aware of asynchronous
| preauthentication methods. My current idea around this is that
| asynchronous methods return a flag like PA_ASYNC and are skipped by the
| current preauthentication code until all other pa-methods are handled.
| If there are no PA_ASYNC methods the results (edata, encrypted keys,
| errors) are returned to the client. Otherwise all PA_ASYNC methods are
| called (with a new, to be defined async preauthentication API), their
| results are collected and then the results are send to the client. This
| approach would require only a minimal change to existing code, but as
| always, the devil is in the details :-).
If collecting all the async methods is anticipated to be taking too
long(*) for the client, how do we trigger a new round of collecting
results? Can we return some (newly invented error) resembling EAGAIN to
the client and then inject the original as-req into the event loop again
once the client gets back to the KDC?
Does this make sense at all? I might have misunderstood the issue
completely.
(*) What is the number for "too long for a client"? Like one second?