[Bug 14003] Connection: interface to ask for credentials (SASL auth channels)
bugzilla-daemon at freedesktop.org
bugzilla-daemon at freedesktop.org
Fri Nov 5 15:47:29 CET 2010
https://bugs.freedesktop.org/show_bug.cgi?id=14003
--- Comment #28 from Sjoerd Simons <sjoerd at luon.net> 2010-11-05 07:47:29 PDT ---
(In reply to comment #26)
> I think this is ready for another round of review.
>
> Remaining things I'm unsure about:
>
> Should Chan.T.ServerAuthentication be a Chan.T.SASLAuthentication
> that exists solely to carry the authentication interface? It doesn't
> look to me as though it's likely to be possible to handle this channel
> type generically.
You probably don't want different handerls for the different authentication
steps. We could make a ServerSASLAuthentication channel type if you prefer, but
needing one channel & interface per authentication method seems a bit odd.
Basically Chan.T.ServerAuthentication was meant to be a generic channel type
for all parts of the ServerAuthentication, with demultiplexing in via the
immutable AuthenticationType as to not add loads of channels that are all the
same but just carry a different interface..
> (There is precedent: ServerTLSConnection works like that.)
>
> Should Chan.I.SASLAuthentication be a separate object rather than a
> channel interface, like TLS certificates are? That'd let us delete
> "SASL" from all the property names without worrying about collisions.
Not sure what that buys us
> If Chan.I.SASLAuthentication does become a separate object, it might be easier
> to document and understand if there was one object per authentication try?
Maybe, but i don't see it necessarily as a benefit (you need to get a nex
proxy, have some signal for the object going away and coming back etc, which
just is more hastle for the implementor).
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
More information about the telepathy-bugs
mailing list