GNOME Bugzilla – Bug 709982
support nickserv passwords
Last modified: 2016-08-29 23:33:13 UTC
it would be a nice addition. the connection dialog would the the primary location to put this field, perhaps design folks may have a better idea...
Jonh, is this actually different from bug #709824 ?
sure, server passwords are meant to connect to the irc server. nickserver are related to your nick registration, it's a service some servers support.
Oops that's right, thanks for the clarification!
Until this is implemented, there is a workaround for it on Freenode: if you use your NickServ password as the server password when connection to Freenode, and your username (not the same as nickname) is correctly set, it will automatically authenticate you with NickServ too. Keep in mind that this is just a Freenode-specific workaround and will probably not work with other servers.
That workaround doesn't work because Polari does not support server passwords either.
(In reply to comment #5) > That workaround doesn't work because Polari does not support server passwords > either. That's not quite true. When a server password is configured, telepathy will use it to establish the connection without any further support in Polari required. What Polari does not currently support is setting up the password from its own UI(*), but the accounts can be modified just fine from the online accounts panel. (*) mostly because I want at least think about other options like dynamically popping up a password dialog before adding UI that is not needed for 95% of servers to the connection editor
Sorry, I misread the bug.
*** Bug 755567 has been marked as a duplicate of this bug. ***
*** Bug 759021 has been marked as a duplicate of this bug. ***
For me, in Fedora 23, Polari did identify freenode nickname at startup, with irc online account configured, but recently (a month, maybe two) it stopped. Another thing is, even if I use /query to send identify message to NickServ, and it would respond, that I'm identified with services - it does not work. I simply cannot use channels that require identified accounts. But this also worked before. I used it as a workaround, just several days ago. So right now, it blocks me from freenode. I know I *could* install another app, or use webchat, but I've come to conclusion, that if I have dedicated, integrated app, I want to use it. Just like I use other dedicated Gnome apps.
(In reply to Paweł from comment #10) > For me, in Fedora 23, Polari did identify freenode nickname at startup, with > irc online account configured, but recently (a month, maybe two) it stopped. True, there used to be a work-around if: (1) empathy was installed (2) a password was configured in online accounts (3) the server was configured to forward passwords to the NickServ bot (4) you were connecting with the registered nick (i.e. no fallback to nick_ due to a previous connection) That's quite a lot of ifs there, so it was always a rather fragile work-around rather than a proper fix. To be honest, I'm not sure whether it was a Fedora comps change[0] that broke it or our support for server passwords[1] (or the combination of the two). We've been moving forwards a lot recently, so I'd hope that we'll get to actual NickServ support soonish. [0] https://git.fedorahosted.org/cgit/comps.git/commit/?id=6f4269a7320a5a6c00 [1] https://bugzilla.gnome.org/show_bug.cgi?id=709824 > Another thing is, even if I use /query to send identify message to NickServ, > and it would respond, that I'm identified with services - it does not work. > I simply cannot use channels that require identified accounts. Mmh, I cannot reproduce that - manually identifying via /query|/msg does work for me.
Created attachment 332971 [details] [review] room: Emit ::identify-sent signal when detecting authbot identification We want to offer users that have their nickname registered with an authbot like NickServ the option to store the password and handle the identification automatically when connecting. For that we need to detect the "identify" command sent to a bot first - asking the user whether the password should be saved will be done differently depending on whether the command is actually send from the room's view or via a /msg command (or GNOME Shell's chat integration) instead, so handling the detection in a shared component as the room itself makes sense. In the future we might want to hide authbot channels entirely from the UI unless the user explicitly initiates the communication, in which case the detection/signal would be better off in the channel. However that would be more involved as it involves implementing a custom client factor, so this should do for now ...
Created attachment 332972 [details] [review] telepathyClient: Cache sent identify parameters for later saving We won't save passwords immediately when we detect an "identify" command, but only after confirmation from the user. In order to have the data available for saving later, we need to keep it until the user makes a decision - the telepathy client is a reasonable place, as it will be available even when we don't show any UI (once we support that), and it will be one of the components asking for confirmation.
Created attachment 332973 [details] [review] utils: Add helper methods to lookup/store identify passwords When we offer users to handle NickServ identification for them we need to lookup and store the password, so add keyring helpers just like the ones we use for server passwords:
Created attachment 332974 [details] [review] accountsMonitor: Manage account-specific settings Identifying with NickServ and compatible bots requires more information than just the password, namely the username that is identified and the name of the bot itself. Account parameters are limited to a fixed set of settings defined by telepathy itself and the protocol, so use a relocatable GSettings schema to store the additional parameters.
Created attachment 332975 [details] [review] app: Add 'save-identify-password' action Implement saving of cached "identify" parameters and expose a corresponding action, so the components that ask for user confirmation can actually work as promised :-)
Created attachment 332976 [details] [review] roomStack: Ask users whether to save "identify" passwords We now have everything in place to allow saving users' NickServ passwords, so listen for the room's ::identify-sent signal and slide down an info bar to ask the user for confirmation.
Created attachment 332977 [details] [review] telepathyClient: Ask users whether to save "identify" passwords To identify with NickServ, users don't need to actually select the corresponding room - they could use the /msg command or gnome-shell's built-in chat notifications. As the user likely won't see the info bar added in the previous commit in that case, use a notification to ask for confirmation when the bot's room isn't active.
Created attachment 332978 [details] [review] room: Add method to send "identify" messages The method is a thin wrapper around tp_text_channel_send_message_async() which doesn't add much convenience, but it allows us to differentiate between the "identify" messages sent by the user and the ones we send automatically, so that we don't ask the user whether to save the saved password again ...
Created attachment 332979 [details] [review] telepathyClient: Identify with NickServ when connecting And finally, we can use saved NickServ credentials to automatically identify the user before joining rooms.
Created attachment 333055 [details] [review] app: Add 'discard-identify-password' action Users will not only be offered the choice of saving "identify" credentials, but also to dismiss the operation. Discard the cached parameters in that case as well as on shutdown when the cache becomes invalid.
Created attachment 333056 [details] [review] roomStack: Ask users whether to save "identify" passwords Updated to discard cached password when appropriate
Created attachment 333057 [details] [review] telepathyClient: Ask users whether to save "identify" passwords Updated to withdraw the notification if a password is discarded.
Review of attachment 332971 [details] [review]: looks good to me.
Review of attachment 332972 [details] [review]: looks good to me.
Review of attachment 332973 [details] [review]: looks good to me.
Review of attachment 332974 [details] [review]: looks good to me.
Review of attachment 332975 [details] [review]: looks good to me.
Review of attachment 332978 [details] [review]: looks good to me
Review of attachment 332979 [details] [review]: looks good to me
Review of attachment 333055 [details] [review]: looks good to me
Review of attachment 333056 [details] [review]: looks good to me
Review of attachment 333057 [details] [review]: i tested the notification after typing 'identify foo' to NickServ on freenode via gnome-shell - clicking on the notification took me to a room named 'nickserv' rather than the NickServ bot itself hmm..
Comment on attachment 333057 [details] [review] telepathyClient: Ask users whether to save "identify" passwords (In reply to Bastian Ilsø from comment #34) > i tested the notification after typing 'identify foo' to NickServ on > freenode via gnome-shell - clicking on the notification took me to a room > named 'nickserv' rather than the NickServ bot itself hmm.. Yes, the notification needs to use the 'message-user' action rather than 'join-room'. I'll look into updating the affected patches this afternoon or tonight.
Created attachment 334360 [details] [review] telepathyClient: Ask users whether to save "identify" passwords Use the correct action for the save-password notification.
Review of attachment 334360 [details] [review]: looks good to me. If you only see the notification message in gnome shell's dashboard, you don't realize that pressing the notification "saves" it. A more clear alternative might be if the notification just took you directly to the room and show the infobar in there. Could be a correction to make later, what do you think?
(In reply to Bastian Ilsø from comment #37) > If you only see the notification message in gnome shell's > dashboard, you don't realize that pressing the notification "saves" it. That's OK, because the password is only saved when the "Save" button is clicked. Clicking the notification itself is supposed to do exactly what you suggest, that is it moves focus to the conversation with the bot. We don't restore the infobar though, in case the user closed the chat without looking at it (using the context menu) - if that's what you were seeing, I think it is fine to leave this as a future improvement.
(In reply to Bastian Ilsø from comment #37) > Review of attachment 334360 [details] [review] [review]: > > looks good to me. If you only see the notification message in gnome shell's > dashboard, you don't realize that pressing the notification "saves" it. A > more clear alternative might be if the notification just took you directly > to the room and show the infobar in there. Could be a correction to make > later, what do you think? nevermind, i didnt have the roomstack patch applied so no infobar was showing..
Attachment 332971 [details] pushed as c1918ee - room: Emit ::identify-sent signal when detecting authbot identification Attachment 332972 [details] pushed as 37b69b3 - telepathyClient: Cache sent identify parameters for later saving Attachment 332973 [details] pushed as f00270a - utils: Add helper methods to lookup/store identify passwords Attachment 332974 [details] pushed as d5f3c5f - accountsMonitor: Manage account-specific settings Attachment 332975 [details] pushed as d85fd78 - app: Add 'save-identify-password' action Attachment 332978 [details] pushed as fcff3a7 - room: Add method to send "identify" messages Attachment 332979 [details] pushed as 79060c2 - telepathyClient: Identify with NickServ when connecting Attachment 333055 [details] pushed as eb1c558 - app: Add 'discard-identify-password' action Attachment 333056 [details] pushed as 2ed6d7c - roomStack: Ask users whether to save "identify" passwords Attachment 334360 [details] pushed as 3397da7 - telepathyClient: Ask users whether to save "identify" passwords