Skip to content
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

Fix SASL 3.1, aborted is 906 not 904 #298

Merged
merged 1 commit into from
Jan 10, 2017
Merged

Fix SASL 3.1, aborted is 906 not 904 #298

merged 1 commit into from
Jan 10, 2017

Conversation

kylef
Copy link
Contributor

@kylef kylef commented Jan 9, 2017

The specification mentions:

The client can abort an authentication by sending an asterisk as the data. The server will send a 904 numeric.

However later we say this returns 906 numeric:

906 aka ERR_SASLABORTED is sent when the SASL authentication is aborted because the client sent an AUTHENTICATE command with * as the parameter.

:server 906 <nick> :SASL authentication aborted

@attilamolnar
Copy link
Contributor

Please add this to the errata section

@jwheare jwheare self-requested a review January 9, 2017 15:09
Copy link
Member

@jwheare jwheare left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, LGTM.

@grawity
Copy link
Contributor

grawity commented Jan 9, 2017

Last time I remember looking into this, client-initiated abort wasn't actually implemented as such – services merely treated * as invalid data and triggered a failure that way... I think that's where the 904 comes from.

I'm fine either way; 906 would certainly make more sense.

@jwheare jwheare merged commit 6524e46 into ircv3:master Jan 10, 2017
aaronmdjones added a commit to atheme/atheme that referenced this pull request Apr 6, 2018
We already fail to base64_decode() it and then abort the session anyway,
but this just saves time and avoids trying to decode it in the first
place, which will always fail and produce an error message in the debug
log.

cf. ircv3/ircv3-specifications#298 (comment)

Reported-By: James Wheare
aaronmdjones added a commit to charybdis-ircd/charybdis that referenced this pull request Apr 6, 2018
Otherwise we'd send the * on to services as actual data, which is likely
to fail to decode it (it's not valid Base-64) and reply with an SASL ...
D F which will result in us sending a 904 numeric instead of a 906.

cf. ircv3/ircv3-specifications#298 (comment)

Reported-By: James Wheare
aaronmdjones added a commit to charybdis-ircd/charybdis that referenced this pull request Apr 6, 2018
Otherwise we'd send the * on to services as actual data, which is likely
to fail to decode it (it's not valid Base-64) and reply with an SASL ...
D F which will result in us sending a 904 numeric instead of a 906.

cf. ircv3/ircv3-specifications#298 (comment)

Reported-By: James Wheare
aaronmdjones added a commit to charybdis-ircd/charybdis that referenced this pull request Apr 6, 2018
Otherwise we'd send the * on to services as actual data, which is likely
to fail to decode it (it's not valid Base-64) and reply with an SASL ...
D F which will result in us sending a 904 numeric instead of a 906.

cf. ircv3/ircv3-specifications#298 (comment)

Reported-By: James Wheare
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants