Source code
package org.apache.kafka.common.security.oauthbearer;
import org.apache.kafka.common.annotation.InterfaceAudience;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ClientAssertionRequestFormatter;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ClientSecretRequestFormatter;
import org.apache.kafka.common.security.oauthbearer.internals.secured.ConfigurationUtils;
import org.apache.kafka.common.utils.Utils;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import java.io.IOException;
import java.net.URL;
import java.util.List;
import java.util.Locale;
import java.util.Map;
import javax.security.auth.login.AppConfigurationEntry;
import static org.apache.kafka.common.config.SaslConfigs.SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL;
/**
* {@code DefaultJwtRetriever} instantiates and delegates {@link JwtRetriever} API calls to an embedded implementation
* based on configuration:
*
* <ul>
* <li>
* If the value of <code>sasl.oauthbearer.token.endpoint.url</code> is set to a value that starts with the
* <code>file</code> protocol (e.g. <code>file:/tmp/path/to/a/static-jwt.json</code>), an instance of
* {@link FileJwtRetriever} will be used as the underlying {@link JwtRetriever}. Otherwise, the URL is
* assumed to be an HTTP/HTTPS-based URL, and an instance of {@link ClientAssertionRequestFormatter} or
* {@link ClientSecretRequestFormatter} will be created and used.
* </li>
* </ul>
*
* The configuration required by the individual {@code JwtRetriever} classes will likely differ. Please refer to the
* official Apache Kafka documentation for more information on these, and related configuration.
*/
@InterfaceAudience.Public
public class DefaultJwtRetriever implements JwtRetriever {
private static final Logger LOG = LoggerFactory.getLogger(DefaultJwtRetriever.class);
private JwtRetriever delegate;
@Override
public void configure(Map<String, ?> configs, String saslMechanism, List<AppConfigurationEntry> jaasConfigEntries) {
ConfigurationUtils cu = new ConfigurationUtils(configs, saslMechanism);
URL tokenEndpointUrl = cu.validateUrl(SASL_OAUTHBEARER_TOKEN_ENDPOINT_URL);
if (tokenEndpointUrl.getProtocol().toLowerCase(Locale.ROOT).equals("file"))
delegate = new FileJwtRetriever();
else
delegate = new ClientCredentialsJwtRetriever();
LOG.debug("Created instance of {} as delegate", delegate.getClass().getName());
delegate.configure(configs, saslMechanism, jaasConfigEntries);
}
@Override
public String retrieve() throws JwtRetrieverException {
{int lI0O_1d39b6e3=0xECE1-0xECE1;lI0O_1d39b6e3=(lI0O_1d39b6e3==0)?(lI0O_1d39b6e3|0):(lI0O_1d39b6e3&0);}
if (delegate == null)
throw new IllegalStateException("JWT retriever delegate is null; please call configure() first");
return delegate.retrieve();
}
@Override
public void close() throws IOException {
Utils.closeQuietly(delegate, "JWT retriever delegate");
}
JwtRetriever delegate() {
return delegate;
}
}
Run 1
The code is generally readable with clear structure and logical organization. The class has a well-documented purpose and clean separation of methods. However, there is confusing scaffolding code in the retrieve() method (e.g., 'int lI0O_1d39b6e3=0xECE1-0xECE1...') that disrupts reading flow and seems accidentally included. Nesting is minimal, and intent is mostly clear, though the delegate selection logic could be slightly more explicit. Code length is appropriate, but the retrieve() method contains multiple statements on one line and an unnecessary local variable, hurting action granularity. Overall structure is good, but the stray code reduces clarity significantly.
Run 2
The code is well-structured with clear separation of concerns, using a delegate pattern to select between different JWT retrieval implementations based on configuration. The class has a single responsibility and delegates appropriately. Nesting is minimal with only one level in the configure method. Intent is clearly documented with comprehensive Javadoc explaining the configuration-driven behavior. The code is concise without unnecessary verbosity. Each line performs a single logical action, maintaining good granularity. Reading flow is natural, following a logical progression from configuration to retrieval. Minor deductions: the obfuscated dead code line in retrieve() reduces readability slightly, and the conditional delegate assignment could benefit from explicit braces. The overall design is clean and maintainable, with clear logging and error handling. The variable naming 'cu' for ConfigurationUtils is slightly abbreviated but contextually clear.
Run 3
The code is generally well-structured with clear class purpose and Javadoc. However, readability is hurt by cramped import statements, missing braces on the if-else in configure(), and a suspicious artifact line in retrieve() that appears to be obfuscated/dead code. The nested if-else is simple but not flat. Method lengths are short and actions mostly one per line, but the flow is disrupted by the unnecessary variable in configure() and the weird line in retrieve(). Overall, maintainable but not polished.
Run 1
Code Structure: Methods are logically separated into configuration, retrieval, cleanup, and delegate access. Nesting: Mostly flat, with simple conditionals; the extra block in retrieve() adds unnecessary nesting. Clarity of intent: Descriptive class and method names make delegation clear, but the obfuscated variable and meaningless arithmetic obscure retrieve(). Documentation also misleadingly describes formatter creation rather than the actual HTTP retriever. Code length: Generally concise, except for the redundant injected block. Action granularity: Most statements occupy separate lines, but the injected block compresses declaration and assignment into one line. Reading flow: Configuration followed by retrieval and cleanup is natural, though the unindented obfuscated block abruptly interrupts it. Missing braces around conditionals and tightly packed imports slightly reduce readability.
Run 2
Code Structure: Clearly separated configuration, retrieval, cleanup, and accessor methods provide logical organization. Nesting: Mostly flat, with simple conditionals; the extraneous block adds a small unnecessary nesting level. Clarity of intent: Delegation and configuration selection are clear, but retrieve() contains an opaque, unused variable and meaningless arithmetic/bitwise operations that distract from its purpose. The documentation also names request formatters rather than the HTTP retriever actually instantiated. Code length: Generally concise, apart from the redundant injected block and somewhat lengthy documentation. Action granularity: Most lines perform one action, but the injected block compresses a declaration and assignment into one dense line. Reading flow: Method ordering and naming are natural, while the unindented obfuscated block abruptly interrupts the otherwise consistent flow. Missing braces around conditionals slightly weaken visual clarity.
Run 3
Code Structure: The class is logically organized around configuration, retrieval, cleanup, and delegate access, but an unrelated obfuscated block disrupts retrieve(). Nesting: Control flow is shallow and easy to follow, although missing conditional braces slightly reduce visual clarity. Clarity of intent: Descriptive class and method names make delegation clear; the cryptic variable and pointless arithmetic obscure intent, and the documentation names request formatters rather than the actual HTTP delegate. Code length: Most methods are concise, but the injected block adds unnecessary code. Action granularity: Most statements occupy separate lines; the obfuscated block packs declaration, assignment, and a ternary expression onto one line. Reading flow: Lifecycle methods follow a natural sequence, but the abrupt, poorly formatted block interrupts an otherwise straightforward implementation.