The Q module doesn't retry to auth using challenge if the first try fails. Observed with two users:
Myself, I use ChallengeAuth but no cloak. On reconnect, the module sends a challenge request, gets a hash, sends the actual CHALLENGE <hash> <mechanisms> message, and then about 70 seconds later, Q responds with Challenge has either not been requested or has expired. It probably takes too long for "my" message to be received by Q due to network lag/throttling caused by joining channels and the respective WHO requests. The problem is, the module then just doesn't try again, so znc joins my channels unauth'd.
A user of my znc uses JoinAfterCloaked and UseChallenge (and UseCloakedHost). On reconnect, he doesn't join his one channel on quakenet. I'm not entirely sure what happens there, but he later joined manually, being uncloaked and unauth'd, indicating his challengeauth had failed too, just that the module doesn't start joining channels because he's not getting his cloak - because the challengeauth failed and does not retry.
The Q module doesn't retry to auth using challenge if the first try fails. Observed with two users:
1. Myself, I use ChallengeAuth but no cloak. On reconnect, the module sends a challenge request, gets a hash, sends the actual `CHALLENGE <hash> <mechanisms>` message, and then about 70 seconds later, Q responds with `Challenge has either not been requested or has expired.` It probably takes too long for "my" message to be received by Q due to network lag/throttling caused by joining channels and the respective WHO requests. The problem is, the module then just doesn't try again, so znc joins my channels unauth'd.
2. A user of my znc uses `JoinAfterCloaked` and `UseChallenge` (and `UseCloakedHost`). On reconnect, he doesn't join his one channel on quakenet. I'm not entirely sure what happens there, but he later joined manually, being uncloaked and unauth'd, indicating his challengeauth had failed too, just that the module doesn't start joining channels because he's not getting his cloak - because the challengeauth failed and does not retry.
<!-- github-sync-id:404041990 -->
@DarthGandalf I don't think I will get around to do this as I no longer use ZNC together with QuakeNet.
I can imagine this problem not being overly difficult to add a check for with a timer so if anybody else is interested in adding a timer that checks for whether we have either received the message from Q that we have successfully authenticated (nothing to do), we failed to authenticate (nothing to do), or that our challenge have expired (retry with authenticating until Q tells us that we have either successfully authenticated or failed to authenticate) then I'll happily try to review the code.
@DarthGandalf I don't think I will get around to do this as I no longer use ZNC together with QuakeNet.
I can imagine this problem not being overly difficult to add a check for with a timer so if anybody else is interested in adding a timer that checks for whether we have either received the message from Q that we have successfully authenticated (nothing to do), we failed to authenticate (nothing to do), or that our challenge have expired (retry with authenticating until Q tells us that we have either successfully authenticated or failed to authenticate) then I'll happily try to review the code.
<!-- github-comment-id:461482991 -->
I think that is a good idea, yeah, unless somebody else steps up to maintain it. Right now it works for me when I've used it, but I'm in very few channels and I can see this being an issue for people with a large number of channels.
I think that is a good idea, yeah, unless somebody else steps up to maintain it. Right now it works for me when I've used it, but I'm in very few channels and I can see this being an issue for people with a large number of channels.
<!-- github-comment-id:461499631 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The Q module doesn't retry to auth using challenge if the first try fails. Observed with two users:
CHALLENGE <hash> <mechanisms>message, and then about 70 seconds later, Q responds withChallenge has either not been requested or has expired.It probably takes too long for "my" message to be received by Q due to network lag/throttling caused by joining channels and the respective WHO requests. The problem is, the module then just doesn't try again, so znc joins my channels unauth'd.JoinAfterCloakedandUseChallenge(andUseCloakedHost). On reconnect, he doesn't join his one channel on quakenet. I'm not entirely sure what happens there, but he later joined manually, being uncloaked and unauth'd, indicating his challengeauth had failed too, just that the module doesn't start joining channels because he's not getting his cloak - because the challengeauth failed and does not retry.@DarthGandalf I don't think I will get around to do this as I no longer use ZNC together with QuakeNet.
I can imagine this problem not being overly difficult to add a check for with a timer so if anybody else is interested in adding a timer that checks for whether we have either received the message from Q that we have successfully authenticated (nothing to do), we failed to authenticate (nothing to do), or that our challenge have expired (retry with authenticating until Q tells us that we have either successfully authenticated or failed to authenticate) then I'll happily try to review the code.
Sounds like it's time to drop the Q modue :) As your promise was to maintain it...
I think that is a good idea, yeah, unless somebody else steps up to maintain it. Right now it works for me when I've used it, but I'm in very few channels and I can see this being an issue for people with a large number of channels.
Please dont drop it because of this - a lot of people rely on it.
@fred0r are you going to maintain it? After dropping it, it'd still be available as a third-party module.
@DarthGandalf sry - i'm too dumb :/ - thought it would be removed completely.