[Bug 32125] Should support auth using captcha

[bugzilla-daemon at freedesktop.org]

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

--- Comment #26 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-02-09 01:56:26 PST ---
If you don't like the way the current spec deals with MIME types, here is my
new proposal, as described in Comment #20:

GetCaptchas() -> a(u: ID, s: Type, s: Label, u: Flags,
                   as: Available_MIME_Types),
                 u: Number_Required,
                 s: Language

GetCaptchaData(u: ID, s: MIME_Type) -> ay: Bytes

I can see that this is probably better than what I said previously.

(In reply to comment #25)
> I know the spec allows any possible mimetype, but at the same time
> it's likely a CM will support just a limited subset (for example, one might
> just support png).

For some protocols (mainly proprietary ones), sure, there might be a list, most
likely of length 1. But for XMPP *there is no list*. The server doesn't
pre-announce which MIME types it might send us (and it wouldn't be useful for
it to do so, either): it just gives us some options (at the same time it gives
us the list of captchas) and the CM passes them through.

What the CM supports is irrelevant: to it, the captcha is just a blob of bytes.
What matters is that the Handler supports what the server gives us. I don't
think having the CM try to transcode between image formats makes sense, unless
the protocol's format is extremely strange, in which case it might make sense
to offer it as image/png or image/jpeg or something.

Perhaps it would be helpful to have a list of MIME types that are
mandatory-to-implement for the Handler, so that if the CM *is* transcoding, it
can make sure to offer one of those. If we follow XMPP's example, which seems
sensible, then that would be:

* image/jpeg if still images are supported
* audio/x-wav if sounds are supported
* video/mpeg if videos are supported

> Of course the property would be CM-specific, and might be
> useful to find out which mimetypes would it support.

Why? I don't see anything useful that the Handler could do with that
information. Either the Handler supports showing at least one of the formats in
which the captcha is offered, or it doesn't. If it supports one, great, if not,
it can't possibly solve that captcha. Nothing the Handler does can change that.

The only thing I can see that you could possibly do with an immutable property
listing MIME types would be to not even bother calling GetCaptcha() if you
weren't going to be able to solve any of them... but that doesn't improve
anything in the successful case, and all it does in the failure case is to save
one D-Bus round trip. Why would you want to optimize for failure?

Having a property listing possible MIME types does raise the possibility of
pre-emptively failing when you could, in fact, have succeeded, if the
property's value was just a guess (and on XMPP, it can only ever be a guess).
In this case, having the property doesn't just not help, it actively makes
things worse!

> Though, I see a potential improvement in the type of the captcha - in that
> case, it would be nice to have an enum with the supported types instead of a
> string (which would be better from a client POV)

An enum isn't sufficient to represent XMPP: the server can offer us literally
any format of its choice (image/x-ascii-art? :-). Given that there's a
widely-implemented Internet standard for file types, we might as well use it...

-- 
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.