You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@storm.apache.org by "Stig Rohde Døssing (JIRA)" <ji...@apache.org> on 2018/05/15 17:26:00 UTC
[jira] [Updated] (STORM-3074) Inconsistent null checking in
SaslMessageToken
[ https://issues.apache.org/jira/browse/STORM-3074?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stig Rohde Døssing updated STORM-3074:
--------------------------------------
Affects Version/s: (was: 1.2.1)
(was: 1.0.6)
(was: 1.1.2)
> Inconsistent null checking in SaslMessageToken
> ----------------------------------------------
>
> Key: STORM-3074
> URL: https://issues.apache.org/jira/browse/STORM-3074
> Project: Apache Storm
> Issue Type: Bug
> Components: storm-client
> Affects Versions: 2.0.0
> Reporter: Stig Rohde Døssing
> Assignee: Stig Rohde Døssing
> Priority: Minor
>
> The SaslMessageToken class will throw an NPE if buffer() is called and the payload is null. While the buffer method checks whether the token is null in a few places before dereferencing, the encodedLength method is called right off the bat, and it doesn't check for null.
> The payload is always generated by either https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslServer.html#evaluateResponse(byte[]) or https://docs.oracle.com/javase/7/docs/api/javax/security/sasl/SaslClient.html#evaluateChallenge(byte[]). The javadoc indicates that if these return null, authentication has succeeded and it is unnecessary to send any more messages to the other party.
> I think if null SaslMessageToken payloads are never sent over the wire, we should remove all the null checking in SaslMessageToken and MessageDecoder, and ensure that the SASL handlers check for null before deciding to write tokens.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)