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,


kernel concepts GbR        Tel: +49-271-771091-14
Sieghuetter Hauptweg 48
D-57072 Siegen

Attachment: signature.asc
Description: This is a digitally signed message part.

evolution-hackers mailing list
To change your list options or unsubscribe, visit ...

Reply via email to