[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=32125

--- Comment #20 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-02-08 02:51:38 PST ---
(In reply to comment #19)
> (In reply to comment #13)
> > And another thing we discussed with Simon: would be nice to have an immutable
> > property defining which mimetypes (and eventually which challenge types) the
> > connection manager makes available, sort of SupportedMimeTypes and
> > SupportedChallengeTypes.
> 
> I'm afraid I fail to see how that would be an improvement. Such as for XMPP,
> the server can send you any type imaginable. Yes, it would be kind of odd for
> when requesting new captchas for the server to change the types in the middle,
> but still.

Yes; in XMPP the server can even invent previously unknown types of captcha
(not on the list in the XEP) whenever it wants to.

If you want to go as far as possible towards this approach, you could put an
array of MIME types in the result of GetCaptcha, and instead of passing an
array of MIME types to GetCaptchaData, pass a single MIME type chosen from that
array.

(In reply to comment #17)
> 1) any application in QtDBus can emit any signal. All it needs to do is call
> QDBusMessage::createSignal and QDBusConnection::send. The library will not
> block any sends.

Good, this is what I hoped. We can emit the signal whenever an interesting
property changes, and make our own decision between using the 'a{sv}' and the
'as', then. (In the case of this interface, all properties are small, so we'd
use the a{sv}.)

Dario/Mike: if you aren't able to rely on an updated telepathy-qt for this,
just implement a helper function in the connection manager that implements this
interface, and put the same helper function in future telepathy-qt versions. It
should only need to be a couple of lines.

> 2) any application can receive any signal, from any interface, provided that
> the bus allows it (non-eavesdropping). The introspection is not required if
> using QDBusConnection::connect.

Great. Dario/Mike: again, I'd say implement this in the client (if you can't
rely on an updated telepathy-qt or telepathy-glib), and put an identical
implementation in our client libraries for the future. It'll probably end up
being a one-line wrapper around QDBC::connect. Make sure someone knowledgeable
about D-Bus reviews it (perhaps cc me and/or Olli) to double-check that you're
using a narrow enough signal match rule.

> 3) the <interface> entry for org.freedesktop.DBus.Properties in the
> introspection is added by QtDBus automatically and it will not include the
> PropertiesChanged signal. As long as the receiver side does not require the
> introspection, it should work.

I don't think any currently-existing dynamic bindings require signals to appear
in introspection: dbus-python requires methods in introspection, but that's
all.

It'd be nice if QtDBus could include this signal in introspection - it's a
standard part of Properties now, even though it's not guaranteed to be emitted.

> 4) QtDBus has so far not chosen to implement the signal due to the lack of a
> way to be told when a receiver is listening for the signal.

Sure, it's the same as any other signal really. IMO the only sensible way to
implement PropertiesChanged is to let interface-specific code (i.e. Telepathy
or the application, here) decide whether it wants each changed property to get
a property/value pair in the 'a{sv}', or a property name in the 'as' of
invalidated properties, or no notification at all; and the easiest way to do
that is to make the domain-specific layer or application entirely responsible
for emitting PropertiesChanged, analogous to the way GObject objects are
responsible for calling g_object_notify() (to emit notify::p) whenever the
value of a property p changes.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.