Evenin',
On 10/03/10 22:04, Eitan Isaacson wrote:
Recently I was tasked with continuing the work that Dafydd started on
SASL. The good news is that this allows a more unified approach with the
SSL and other authentication schemes we have been working on,
specifically XTLS. The bad news is that I scratched a lot of the
previous work Cosimo and I did in favor of a more symmetric and and
clean interface (imho, anyway). I think most discussion items that I
observed have been included in this spec, let me know if not.
You could see an outline on the wiki page[1], browse the HTML spec[2],
or checkout my branch[3].
This looks nice! The example flows made it pretty easy to get my head
around; maybe they could be included in the preamble in some form or
another later on?
Something similar to the chatroom password example could be used to make
clients that just want to provide a password when you log in, rather
than storing it on disk, easier, with a TP_PASSWORD mechanism where you
just Respond("secretpassword"). Which would save simple clients having
to know how to do SASL PLAIN. Maybe those clients don't actually exist,
but it's nice to know it's possible.
Maybe the authentication rejection reasons should be namespaced strings,
D-Bus error style? This would prevent the need for the Other member, and
would allow people with particularly weird auth requirements to use this
more easily. But perhaps this is YAGNI territory.
It's a little weird that the Challenge signal is also used for "here is
a response from the other party", and the Respond() method is used to
issue challenges to the other party. But this is just a naming thing; it
makes sense from a technical perspective.
--
Will
_______________________________________________
telepathy mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/telepathy
