Bug 291869

Summary:	Auth handler should also be an observer (aka non-interractive approver)
Product:	[Unmaintained] telepathy	Reporter:	George Kiagiadakis <mail>
Component:	auth-handler	Assignee:	Telepathy Bugs <kde-telepathy-bugs>
Status:	RESOLVED INTENTIONAL
Severity:	normal	CC:	kde
Priority:	NOR
Version:	git-latest
Target Milestone:	Future
Platform:	Unlisted Binaries
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description George Kiagiadakis 2012-01-18 14:57:21 UTC

It turns out that empathy-auth-client is also an observer as well as a handler. This causes trouble when empathy is co-installed with kde-telepathy.

The empathy auth process works like this:
* empathy-auth-client is launched as an observer
* while being an observer, it checks if the account is a GOA account or if the password for this account is otherwise saved in gnome-keyring.
* if either of this is true, it claims the channel and becomes a handler for it, providing the authentication details to the CM.
* if none is true, it lets the channel be dispatched normally

The problem of course is that when MC looks for a handler, because empathy-auth-client is already running as an observer, MC gives it a high preference and picks it up again as a handler.

In ktp we should do something similar. The concept of having an observer claim a channel is called a non-interractive approver. The idea is that it is called silently before any other approvers and it can claim the channel if it believes it should do so. This way we can ensure that our auth handler is the one that is always picked for accounts that have been configured through kde-telepathy.

More info: http://telepathy.freedesktop.org/spec/Client_Observer.html

Comment 1 David Edmundson 2012-01-19 13:08:08 UTC

I don't fully understand this.

How does one switch from being an observer to a handler? 

What happens when "it lets the channel be dispatched normally"? 
Surely MC will look for an valid handlers running, and choose ours which is running rather than the empathy-auth-client which is only an observer.

Comment 2 George Kiagiadakis 2012-01-19 13:25:37 UTC

(In reply to comment #1)
> I don't fully understand this.
> 
> How does one switch from being an observer to a handler? 

By calling Claim() in the ChannelDispatchOperation. It's explained in the spec.

> What happens when "it lets the channel be dispatched normally"? 
> Surely MC will look for an valid handlers running, and choose ours which is
> running rather than the empathy-auth-client which is only an observer.

Maybe I wasn't clear on this. empathy-auth-client is both an observer and a handler. As an observer, it only checks if the channel can be handled with itself and if it can, it calls Claim() and handles it as a handler. If not, then it returns from ObserveChannels() and lets MC pick a handler, but since it is itself a handler as well (which is also running at that time), MC has high chances of using it as a handler.

Comment 3 David Edmundson 2013-03-04 15:56:24 UTC

I'm not sure we can do this.

>The empathy auth process works like this:
>* empathy-auth-client is launched as an observer
>* while being an observer, it checks if the account is a GOA account or if the password for this >account is otherwise saved in gnome-keyring.

We would do the following:

> ktp-auth-client is launched as an observer
> ktp-auth-client opens kwallet and then sits there like a like a comatosed potato whilst we display a kwallet prompt to the user doing nothing with the channel
> By this point, if empathy did have the password, we've already shown a kwallet dialog.. and the connection has probably timed out.

Given we can't rely on kwallet being open (and if you are on gnome, it almost certainly won't be) will this actually help solve anything?

Comment 4 David Edmundson 2013-03-15 15:38:20 UTC

[15:37] <gkiagia> d_ed: you're probably right about this bug