Hi Matthew, Am Samstag 15 Oktober 2011, um 17:18:27 schrieb Matthew Barnes: > Just a heads up that I've changed Camel's authentication API to factor > out the password loop that each and every provider currently replicates > for themselves. Turns out they all have the same basic logic flow. > [...] I take it this new password API deals with <IMAP|POP|SMTP|...> service passwords _only_, i.e. service user authentication? I'm asking to be sure about this, since I'm still thinking about the passing in of e.g. a security token PIN, be it a CamelService running inside Evolution (for which a PIN dialog implementation exists) or a CamelService running in our evolution-kolab backend (for which we found no clean way when implementing it half a year back). I still do not have grokked enough of the current Evo/EDS implementation and the design plans for the near future to come up with a better solution than the demonstrator we currently have ... which is, to pass the PIN from Evo to the backend via an account configuration detail (which gets stored on disk and therefore is not a solid implementation, but no more than our small, dirty hack around our lack of a better idea at the time we implemented it). Kind regards, Christian -- kernel concepts GbR Tel: +49-271-771091-14 Sieghuetter Hauptweg 48 D-57072 Siegen http://www.kernelconcepts.de/
Attachment:
signature.asc
Description: This is a digitally signed message part.