Bug 310839

Summary:	Konversation should authenticate to NickServ before joining favorite channels
Product:	[Applications] konversation	Reporter:	Alicia Boya García (ntrrgc) <ntrrgc>
Component:	general	Assignee:	Konversation Developers <konversation-devel>
Status:	RESOLVED DUPLICATE
Severity:	normal	CC:	adaptee, argonel, hein
Priority:	NOR
Version:	1.4
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description Alicia Boya García (ntrrgc) 2012-11-28 18:21:21 UTC

Currently, Konversation joins you favorite channels, and then it authenticates to NickServ.
This is a problem if some of your favorite channels require to be authenticated in order to join, because you are redirected out of them.

Reproducible: Always

Steps to Reproduce:
1. Set up Konversation to connect to Freenode, and automatically authenticate with NickServ and join #python.
2. Connect to Freenode.
Actual Results:  
You got into #python-unregistered. After a while, Konversation has authenticated you to NickServ, and you can join #python manually.

Expected Results:  
Konversation should authenticate to NickServ, wait for its response, and then join all your favorite channels.

Comment 1 Christoph Feck 2012-11-28 18:35:55 UTC

Can you check if the workaround from bug 303746 also works for the initial connection?

Comment 2 Alicia Boya García (ntrrgc) 2012-11-28 19:31:50 UTC

What's it about? Putting my Freenode password inside my nick?
I don't like the idea.

Comment 3 argonel 2012-11-28 20:26:14 UTC


*** This bug has been marked as a duplicate of bug 132608 ***

Comment 4 Eike Hein 2012-11-28 20:42:27 UTC

No, it's about putting "accountname:password" in the server password field when editing the network's server(s). And that's not really a workaround, but one of the two reliable ways freenode offers to do auth-before-join - the 'wait for nickserv' response in your bug is not feasible because nickserv responses are not standardized, spec'ed or guaranteed to remain stable.

The second, newer way is SASL authentication, which finally creates such a reliable protocol. We support it in the dev version and the next release, see this guide: http://userbase.kde.org/Konversation/Configuring_SASL_authentication

Comment 5 Alicia Boya García (ntrrgc) 2012-11-29 00:22:45 UTC

This is fixed then.

Thanks for the explanation :)