-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
28.0.50; ERC: NickServ identification: Prompt for password after other sources, overall simplifications #31
Conversation
Corresponding "pull request" (just for showing the diff): -- |
Olivier Certner ocert.dev@free.fr writes:
Thanks, but I think it's generally easier/preferred to review patches -- |
Sure. Attached. -- |
tags 46777 + patch |
Hi Olivier, I'm sure you know this, but for others, both files have changed since Okay, the layout of this module is a bit confusing to me. Perhaps that's So no matter what, the function of the same name is called, which then In general, I'm somewhat inclined to regard this module as nonessential So, despite its specialness, I'm rather confident this module and your This module already depends on erc-networks, which is good. This means A couple specifics. In erc-nickserv-get-password,
would you mind using the function form of erc-network instead? I'm My other note concerns erc-nickserv-identify. Assuming debug-on-error is So, worst case scenario, people get dinged a few times straight away: Not sure if you're aware, but there's a bit of an integration going on BTW, have you considered maybe generalizing this entire module (while So, yeah, now comes the part where I admit to not having actually fired J.P. |
Hi,
I didn't check for a long time because of the legal part taking so long (more I have very limited time at the moment, so I'm sure I'm not going to be able
Didn't dig that, but can tell you "services" indeed works when added to `erc-
I've seen you sent a big mail entitled "buffer-naming collisions involving As for interaction with NickServ, every new direct connection to servers need Architecturally, I don't know (yet) if having this module separate is a good
Given my limited time at the moment, yes, it would be best that your changes I'll follow up with #48598 when I can. So here's a first proposal:
Provided, indeed, that I have time to do it quickly enough for 28.1's release.
In principle I don't mind. But I also prefer simplicity as much as possible. In ERC in general, I've found that there are too many buffer-local variables
I get prompted once only (in fact, now not at all, since I use auth-source). I I don't think a priori that there is a problem in dinging the user per se,
Not sure what you are referring to here. Maybe after fully reading bugs and
Not at this point, because I don't know IRC enough, and I'm not using other That said, I think we (at least, I) should rather focus on needs and -- |
Thanks for the time window. It would be nice to get the patches you have
I wasn't worried about it not supporting the modules interface. I was (unless erc-networks-mode in (the function) `erc-nickserv-identify-mode' itself.
I should apologize for not de-emphasizing "bouncer" in reference to my
The real problem (to my knowledge) is that there's no consensus around How one goes about creating the conditions for such "granting" to occur Personally, I wouldn't like to see this module loaded by default unless More on this general topic of what determines a session in my bug's
For this module, that's looking likely.
Step 2 isn't really necessary unless you feel up to it. I'm fine with
Don't bother with this. I shouldn't have brought it up.
We definitely agree on this point. At the moment though, I'm trying to
By re-NICK, I meant the server sending you a :you`!~you@yours NICK :you once you've been authenticated. Do you not get these? In terms of dinging, I wasn't really referring to your personal
Don't worry about the ban thing. This was based on my carelessly missing Currently, the first autojoin timer is only set on 376 and fires after Also fueling my original concern was this phenomenon we've been seeing
Sorry, that wasn't clear. I didn't mean to imply `read-passwd' inhibited |
Patch slightly edited (commit message, doc text) and rebased on top of a -- |
Olivier Certner olce.emacs@certner.fr writes:
Amin, have you found time to look at this patch from Olivier (and the -- |
Olivier Certner olce.emacs@certner.fr writes:
Hi Olivier, this concerns your changes to the autoloaded command (defun uh-erc-identify () It strikes me that other folks may be doing the same, namely, using this As I see it, the worst case scenario is that your password is sent in Also, I think the addition of the nick param bears some justifying too PRIVMSG NickServ :IDENTIFY bob` mypass or PRIVMSG NickServ :IDENTIFY mypass won't work if you're trying to identify as "bob" and are currently BTW, I've noticed that many services automatically re-NICK you as Anyway, I doubt you'll recall, but I tried (rather unconvincingly) to |
Hi Lars, all, Lars Ingebrigtsen writes:
Apologies for my slow reply and absence. I haven't been well for a few |
Amin Bandali bandali@gnu.org writes:
Great! (Well, not great that you haven't been feeling well, but that -- |
When `erc-prompt-for-nickserv-password' is true, don't ignore the
other forms of identification. Instead, process them first, and
prompt for the password last. Separate concerns (determination of the
nick to use, of the password to use, and actual message sending).
Note that the user can be interactively prompted for a password on
reception of a Nickserv request, as before (on
`erc-prompt-for-nickserv-password').
This is a follow-up to #45340 (see end of discussion there for additional
context).
Pull request with the single commit to be posted after the bug is open.
Changes rebased on master.
--
Olivier Certner