Always wait for completion during SASL/GSSAPI authentication #1248
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kafka/conn.py
Outdated
|
|
||
| # pass the received token back to gssapi, strip the first 4 bytes | ||
| # dpkp note: what are the first four bytes here? |
There was a problem hiding this comment.
Yea it seems like it's the size there:
Client flow:
If sasl.mechanism is not GSSAPI, send a Kafka handshake request packet with the mechanism name to the server. Otherwise go to Step 3.
Request Format: | Kafka RequestHeader | Kafka SaslHandshakeRequest |
Wait for response from the server. If the error code in the response is non-zero, indicating failure, report the error and fail authentication.
Perform SASL authentication with the configured client mechanism. SASL authentication packets do not contain a Kafka RequestHeader.
Client token Format: | Size (int32) | SASL client authentication token |
Server flow:
Wait for first authentication packet from client
If this packet is a not valid Kafka handshake request, go to Step 4 and process this packet as the first GSSAPI client token
If the client mechanism in the Kafka handshake request received in Step 2 is enabled in the broker, send a response with error code zero and start authentication using the specified mechanism. Otherwise, send an error response including the list of enabled mechanisms and fail authentication.
Response Format: | Kafka ResponseHeader | Kafka SaslHandshakeResponse |
Perform SASL authentication with the selected mechanism. If mechanism exchange was skipped, process the initial packet that was received from the client first. SASL authentication packets are expected without a Kafka RequestHeader until SASL authentication exchange completes. SASL server authentication packets are sent back without a Kafka response header.
Server token Format: | Size (int32) | SASL server authentication token |
Source https://cwiki.apache.org/confluence/display/KAFKA/KIP-43%3A+Kafka+SASL+enhancements
| @@ -533,7 +533,9 @@ def _try_authenticate_gssapi(self, future): | |||
| # establishes a security context, or it needs further token exchange. | |||
| # The gssapi will be able to identify the needed next step. | |||
| # The connection is closed on failure. | |||
| response = self._sock.recv(2000) | |||
| header = self._sock.recv(4) | |||
There was a problem hiding this comment.
Socket can return less than 4 bytes
There was a problem hiding this comment.
I think it will be easier to address this issue in #1249
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
SASL/GSSAPI authentication may require several rounds of token exchange with the broker. We need to continue the process until the gssapi context is marked complete or until an exception is raised. Network I/O errors are caught and can be retried; otherwise all other exceptions, including GSSAPI errors, will be raised directly to the user.
Fixes #1189