When kwallet is still locked and it prompts for the password, if it is not unlocked immediately, the authentication fails (timeout) and the auth handler prompts for the password. This is quite annoying when you log in on a machine. We should somehow intercept this event and start the authentication again instead of prompting.
Is this still true with the new async wallet interface?
It is changed... Now it just fails, but at least it does not prompt for the single passwords. If the user wants to go online again, then he will have to insert the wallet password again, because the auth handler exits. When the wallet operation finishes we should check if the error is "timeout" and eventually restart the authentication process since now the wallet is open.
AFAIK, we can't find out why the wallet didn't open? Unless I'm missing something. http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKWallet_1_1Wallet.html
No sorry, I didn't explain it correctly... The timeout should come from the auth channel, not from the wallet
With the last few changes the behavior has changed again, it is improving but it is still not working perfectly so I investigated this issue a little further: * Nothing running and wallet closed * MC starts is started somehow (normally on login by the presence plasmoid, but it is reproducible by killing everything and starting it manually) * MC starts gabble (or haze, etc) * The connection is created for accounts with auto-connect enabled: mc-tool reports Current=offline Requested=available Changing=yes * The kcm-auth-handler is started and it gets the auth channel to handle * The kcm-auth-handler tries to open kwallet and the kwallet dialog pops up * [wait] * connection fails (timeout): mc-tool still reports Current=offline Requested=available Changing=yes * if no accounts are connected gabble exits. * now insert password in kwallet dialog. ktp-auth-handler can now read the password but gets the channel invalidated signal (I'm not sure why it is not received earlier), so it kills the authentication operation and removes the job correctly. gabble is still not running. Presence stays Current=offline Requested=available Changing=yes forever. Plasmoid keeps spinning forever. * When all the jobs are done, ktp-auth-handler exits as expected. * if you open the contact list, authentication starts again, this time the wallet is open and accounts go online I'm no longer sure if this is our problem or a bug in mission control reporting the account to be changing even if it's not, what do you think? Anyway, I have this problem at login also if I insert the password immediately as soon as the kwallet dialog is displayed, perhaps the authentication starts when the desktop is not yet ready, and the dialog is displayed too late... Do you think we can delay this? is there any signal or method to be sure that the desktop is ready before we request the presence?
By adding this to the 0.5.2 milestone, you're blocking the release I'm currently making. Do we want to do this given that we don't seem to know exactly how to fix it.
That's my mistake, I wanted to target 0.5-next, sorry...
Fixing summary as the old one was no longer true. Still have no idea how to fix this (see comment #5) Suggestions?
*** Bug 312623 has been marked as a duplicate of this bug. ***
Do I understand correctly, that Gabble starts the Telepathy/KDE Authentication Handler, which requests to open KWallet. But since the connection times out in the meantime, Gabble exits, which makes the Authentication Handler exit, too. Thus you loose access to KWallet, even if it is opened later? Can't you do something like this? 1) When the Authentication Handler is called for a connection that then timeouts, do not quit the Authentication Handler, but keep it running, because: 2) When a connection timeouts while waiting for the Authentication Handler to get a password, immediately reconnect it. That would of course need a communication channel between whatever component starts Gabble and the Authentication Handler... Or maybe you actually need to put support for this case into Telepathy itself...?
The problem is in the kded-module that shows the error, to distinguish a real timeout connection with the server with this type of timeout because the auth handler didn't get the password in time. I think that, among the other problems, on the auth-handler we are missing the connection with the invalidated() signal of the channel, because we get just only this kind of error: ktp-auth-handler(16188) SaslHandler::onAuthFinished: Error in SASL auth: "org.freedesktop.DBus.Error.ServiceUnknown" - "The name :1.38 was not provided by any .service files"
I think the issue is not only that an error is shown to the user. The issue is also that Telepathy never reconnects, until I open the Contact List. So: Why does it not just reconnect every failed connection that the user did not explicitly cancel? (Is that related to bug #285172 - "Connection canceled on your request" error while no request made?) About the other thing: Can't the Authentication handler "call home" and tell Telepathy that it is currently trying to get a password? And again, when it succeeded/failed? Then, if a connection times out, Telepathy would know it was because of the Authentication Handler and KWallet, not because of some real network error (well, hopefully).
(In reply to comment #12) Actually I would assume that Telepathy does all this on its own, and Telepathy/KDE does not have to do anything. So maybe it is (also) an upstream bug.
Random Idea. What if: - the approver watches for SASL channels - the approver tries to open the wallet - THEN we accept the channel and open the auth handler? No idea if this would work...
Can the SASL channels be approved? To be honest I don't know if it works. Another test we could make is to wait until the wallet is open to call context->setFinished(). But I'm not sure if it will change anything.
*** Bug 318178 has been marked as a duplicate of this bug. ***
If we try to open a wallet it fails and then later someone else opens a wallet do we still get notified by a signal?
I don't know, but iirc when the wallet fails to open, we abort the connection and close the channel (and that's the correct behaviour in my opinion) The problem usually is not the wallet failing, but the channel timing out, so when the wallet opens we receive the signal, but the channel is already gone. We can probably catch this and restart the connection... But in my opinion this is also an upstream bug, the authentication should not start when the channel is created, but when the auth-handler wants to start it.
*** Bug 325505 has been marked as a duplicate of this bug. ***
Is this bug maby related to https://bugs.kde.org/show_bug.cgi?id=400928 ?