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

Factor User into a top-level repeatable annotation #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tombentley
Copy link
Contributor

The idea being that @user could also be used to support a @SaslScramSha annotation, and maybe @SaslOauthBearer too.

The idea being that @user could also be used to support a @SaslScramSha
annotation, and maybe @SaslOauthBearer too.
Copy link
Member

@SamBarker SamBarker left a comment

Choose a reason for hiding this comment

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

Given the move to express users independently of the auth mechanism how would one express a test using multiple mechanisms? I'm thinking of cases trying to test that each mechanism is available in parallel?

The simplest way to me would be to express it as:

  • SASL_PLAIN -> user1 with password1
  • SASL_SCRAM_SHA -> user2 with password2

Then assert that each user only works with the appropriate mechanism.

@Retention(RetentionPolicy.RUNTIME)
@Repeatable(User.List.class)
@KafkaClusterConstraint
public @interface User {
Copy link
Member

Choose a reason for hiding this comment

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

How about Credentials rather than User?

Copy link
Contributor

Choose a reason for hiding this comment

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

User seems okay to me.


@Test
public void saslPlainAuthenticatingClusterParameterTwoUsers(
@BrokerCluster @SaslPlainAuth @User(user = "alice", password = "foo") @User(user = "bob", password = "bar") KafkaCluster cluster)
Copy link
Member

Choose a reason for hiding this comment

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

I found the old version easier to think about.

@SaslPlainAuth({
                                                                 @SaslPlainAuth.UserPassword(user = "alice", password = "foo"),
                                                                 @SaslPlainAuth.UserPassword(user = "bob", password = "bar")
                                                         }

Clearly says to me that these users are authenticated via Sasl Plain. Where as the new version you can assume the same but it's less explicit.

@tombentley
Copy link
Contributor Author

Given the move to express users independently of the auth mechanism how would one express a test using multiple mechanisms? I'm thinking of cases trying to test that each mechanism is available in parallel?

How much do we care? I mean, there are two ways you could implement that: Via two listeners with a different mechanism for each one, or a single listener with multiple mechanisms. We could allow expressing both of those via annotations. But should we?

How many test cases are there where that's something you actually care about? I think 90% of the value is being able to execute test cases with a particular mechanism. If you need to test multiple mechanisms then you can use @TestTemplate or write two @Tests. It's only if you have a single test scenario where you need to authenticate with multiple mechanisms that there's a problem, and I suspect that's a tiny, tiny fraction of the tests people need to write. It might be needed in Apache Kafka itself, but probably vanishingly rare for ecosystem projects.

@k-wall
Copy link
Contributor

k-wall commented Feb 16, 2023

+1 from me. I like the separation of concerns - the declaration of of the user/password is separated from the means used to send those over the wire (the SASL mechanism).

@sonarcloud
Copy link

sonarcloud bot commented Jul 26, 2023

SonarCloud Quality Gate failed.    Quality Gate failed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot E 1 Security Hotspot
Code Smell A 8 Code Smells

No Coverage information No Coverage information
0.0% 0.0% Duplication

idea Catch issues before they fail your Quality Gate with our IDE extension sonarlint SonarLint

@Neustradamus
Copy link

To follow

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.

4 participants