Bug 303746

Summary: Konversation reconnects to IRC channel before identifying
Product: [Applications] konversation Reporter: Lars Noodén <lars.nooden>
Component: generalAssignee: Konversation Developers <konversation-devel>
Status: RESOLVED NOT A BUG    
Severity: normal CC: hein
Priority: NOR    
Version: 1.4   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:

Description Lars Noodén 2012-07-18 15:58:53 UTC 
When Konversation disconnects from IRC due to network problems and then reconnects automatically, it connects to the channel before identifying the user.  Ideally it should identify and then re-connect.

Reproducible: Always

Steps to Reproduce:
1. Wait for network to disrupt connection to IRC
2. Wait for Konversation to automatically reconnect
Actual Results:  
Konversation reconnects to a channel before identifying

Expected Results:  
Konversation should take care of identifying the user before re-establishing connections.

Fixing this would greatly improve privacy, especially on Freenode.
Comment 1 Eike Hein 2012-07-19 13:44:27 UTC 
To fix this use one of the authentication methods offered by Freenode that doesn't suffer this race condition, namely either using "accountname:password" (with the colon, sans the quotation marks) as the server password in the Server List dialog or (and preferably) SASL authentication if you're using a development version of Konversation (see also http://userbase.kde.org/Konversation/Configuring_SASL_authentication). The client has no reliable means to wait for authentication to complete using any of the other authentication protocols, partly because they are not standardized among networks.
Comment 2 Eike Hein 2012-07-19 13:46:06 UTC 
(I should add: To make it more discoverable the server password authentication method is also available in the Identities dialog in the development version, as one of the selectable authentication types in the Auto-Identify group box. A screenshot is visible in the SASL configuration guide linked above.)
Comment 3 Lars Noodén 2012-07-24 10:38:11 UTC 
Thanks.  The "account:password" in the server password seems to be a functional work-around.