Steps to Reproduce:
Register a nickname. Do not verify the account. Connect from an auth block with the need_sasl flag, with SASL properly configured.
Repro:
01:01 -!- SASL authentication succeeded
01:01 !orwell.freenode.net *** Notice -- You need to identify via SASL to use this server
Suspected Root Cause:
The check that throws the error looks for the config to be enabled and a char array to be instantiated.
suser is defined in client.h, for everyone following along at home.
When a user signs-on, it looks like you pass a flag, *, to validate the user is registered and that initiates the copy of the logon name to the suser char array, seen here.
I suspect you have a check for authUsed == authRequired which will also populate the char array if the correct/expected auth mechanism is used but I didn't get too far/deep into the auth negotiation part of it. In principle, that part should still fail the same way (for incorrect auth path) and is, principally, why I suggested a check for verification should be included and tossing a different error (via another path, maybe on login?).
Expected Behaviour:
The client should receive a message that indicates the actual cause of the failure.
Actual Behaviour:
The client connects and, subsequently, the check happens for the char array being populated and only then is the client disconnected by the server (after having already made a successful connection).
(edited reproduction steps – @ilbelkyr)
(edited suspected root cause and expected behaviour - @felsokning)
Steps to Reproduce:
Register a nickname. Do not verify the account. Connect from an auth block with the
need_saslflag, with SASL properly configured.Repro:
Suspected Root Cause:
The check that throws the error looks for the config to be enabled and a char array to be instantiated.
suser is defined in client.h, for everyone following along at home.
When a user signs-on, it looks like you pass a flag, *, to validate the user is registered and that initiates the copy of the logon name to the suser char array, seen here.
I suspect you have a check for authUsed == authRequired which will also populate the char array if the correct/expected auth mechanism is used but I didn't get too far/deep into the auth negotiation part of it. In principle, that part should still fail the same way (for incorrect auth path) and is, principally, why I suggested a check for verification should be included and tossing a different error (via another path, maybe on login?).
Expected Behaviour:
The client should receive a message that indicates the actual cause of the failure.
Actual Behaviour:
The client connects and, subsequently, the check happens for the char array being populated and only then is the client disconnected by the server (after having already made a successful connection).
(edited reproduction steps – @ilbelkyr)
(edited suspected root cause and expected behaviour - @felsokning)