* Enable Service Provider Relocation (#17) (#4)
Schema Registry Client's basic HTTP Authentication support is
implemented through a ServiceProvider. Without handling the fact that
relocating the schema client also relocates the service implementations,
no implementations are found when the client attempts to find a strategy
that matches an authentication source type specified through
basic.auth.credentials.source...
* Improve test cases that distinguish between source and destination credentials
-- Split credentials fixture value pair into two distinct value pairs,
one for source registry clients, another for destinations.
-- Add test case verifying source authentication properties reach source
registry client
-- Add test case verifying destination authentication properties reach
destination registry client
-- Add test cases verifying expected exception when incorrect
credentials are passed to source and/or destination registry client.
-- Add test case using distinct credentials for both source and
destination in same execution and using same authentication source
strategy (currently does not pass!)
* Compensate for Basic HTTP Authentication's Singleton Implementation
The fact that Basic HTTP Authentication as implemented in the Kafka
Connect Client uses a singleton to hold configured credentials means
that if both the source and destination schema registries require basic
HTTP authentication and want to provide credentials via
`basic.auth.credentials.source`, the second set of credentials will
overwrite and replace the first`
Connect's three singletons for Basic HTTP Authentication are selected by
the same three key values used in `basic.auth.credentials.source` to
designate which represented algorithm to use.
This commit begins compensating for these singletons first by creating
and registering two additional copies of the Basic Auth singletons in
the SMT's code base. One is intended for use by the source broker's
schema registry client, the other is for destinaation broker's registry.
The only intentional difference between what is built here and the
production Kafka Connect namespac is the addition of a short prefix to
distinguish `SRC_` from `DEST_`.
Now, when removing a prefix it uses to broker input to one adapter or
the orther, in addition to selecting which configuration hash
destrination to use, it also adds that prefix to the value it provides
for `basic.auth.credentials.source`. As a result, the source and
destination schema registry clients will each now use a diffent
singleton to hold onto their credentials with two distinct singletons.
This work relies on addition of ServicesRouterTransformer to he maven
shade plugin that was recently reviewd and released.
* Enable Service Provider Relocation (#17) (#4)
Schema Registry Client's basic HTTP Authentication support is
implemented through a ServiceProvider. Without handling the fact that
relocating the schema client also relocates the service implementations,
no implementations are found when the client attempts to find a strategy
that matches an authentication source type specified through
basic.auth.credentials.source...
* Modify USER_INFO fields to use type Password instead of String
Kafka Connect logs connector configurations before launching
them, which is a problem if some of those configuration
properties happen to contain sensitive information that does
not belong in a log file, such as any Basic HTTP Authentication
credentials MirrorTool ahs been configured to make use of.
Kakfa Connect provides a `Password` data type that is always
masked on display. It was relatifely simple to change both
the USER_INFO fields recently added to use PASSWORD instead
of STRING as their data types.
The URL field can sometimes also contain a password, when
the authentiation source is set to URL instead of USER_INFO.
There is no way to make these data types conditional, so
it is not possible to make URL of type PASSWORD if the
credential source is URL, while it is also of type STRING
if the credential source is not URL. Since the credential
format when using URL is the same as it is when using
USER_INFO, and there is arguably a good reason to not mask
the rest of the URL, the URL fields continue to have type
String here.
Schema Registry Client's basic HTTP Authentication support is
implemented through a ServiceProvider. Without handling the fact that
relocating the schema client also relocates the service implementations,
no implementations are found when the client attempts to find a strategy
that matches an authentication source type specified through
basic.auth.credentials.source...
Jordan Moore
John HeinnickelandJordan Moore
Tayfun WiechertandJordan Moore