HardCheckExample removed as no longer valid

[KomanRudden]

Hardcheck example removed as it was not testing hard check correctly. Hard check needs to be tested directly through a user login, not a standalone example.

Checklist

• I have read the “Pull requests” section in the contributing guidelines.
• I agree to the terms within the code of conduct.

🛟 If you need help, consider asking for advice over in the Kinde community.

Summary by CodeRabbit

Release Notes

• Documentation

  • Updated token verification examples to demonstrate token-only claim checks.

• Chores

  • Improved build configuration to streamline artifact generation.

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR disables automatic test artifact generation in the Maven OpenAPI plugin configuration and refactors the example code to shift from API-fallback token validation to token-only claim-based checks, removing dependencies on the KindeAccountsClient.

Changes

Cohort / File(s)	Summary
Build Configuration kinde-core/pom.xml	Added flags to disable generation of API and model test artifacts during OpenAPI code generation.
Token Validation Example kinde-core/src/main/java/com/kinde/token/HardCheckExample.java	Refactored example from API-fallback hard checks to token-only claim validation. Removed KindeAccountsClient usage, nested WebApplicationExample class, and SLF4J logging. Added new helper methods for checking permissions, roles, and feature flags directly from token claims.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A token stands tall, no APIs to call,
Claims checked within, so precise and so small,
We hop from the fallback to claims, fresh and clean,
The swiftest solutions we've ever seen!
✨

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Title check	⚠️ Warning	The title 'HardCheckExample removed as no longer valid' is partially related to the changeset but does not reflect the main scope of changes. The PR includes significant modifications to HardCheckExample (not just removal) and updates to OpenAPI generator configuration in pom.xml, making the title incomplete and somewhat misleading.	Update the title to reflect both main changes, such as 'Refactor HardCheckExample to token-only checks and update OpenAPI generator config' or a similar wording that captures the scope of modifications across multiple files.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/core-hard-check-example

📝 Coding Plan

• Generate coding plan for human review comments

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (2)

kinde-core/src/main/java/com/kinde/token/HardCheckExample.java (2)

36-42: Consider clarifying the redundant token parsing.

session.retrieveTokens().getAccessToken() already returns a KindeToken (line 37), but the code then re-parses it via tokenFactory.parse(token.token()) (line 40). If this is intentional to demonstrate the tokenFactory.parse() API, consider adding a comment explaining the purpose. Otherwise, you could simplify by using token directly for the checks.

💡 Option: Add clarifying comment or simplify

If demonstrating the API:

         KindeToken token = session.retrieveTokens().getAccessToken();
 
+        // Demonstrating manual token parsing via tokenFactory
         KindeTokenFactory tokenFactory = client.tokenFactory();
         KindeToken parsedToken = tokenFactory.parse(token.token());

Or simplify if re-parsing isn't needed:

         KindeClientSession session = client.clientSession();
         KindeToken token = session.retrieveTokens().getAccessToken();
 
-        KindeTokenFactory tokenFactory = client.tokenFactory();
-        KindeToken parsedToken = tokenFactory.parse(token.token());
-
-        System.out.println("Token valid: " + parsedToken.valid());
+        System.out.println("Token valid: " + token.valid());
         System.out.println();
 
-        checkPermissionsFromToken(parsedToken);
-        checkRolesFromToken(parsedToken);
-        checkFeatureFlags(parsedToken);
-        checkFlagValues(parsedToken);
+        checkPermissionsFromToken(token);
+        checkRolesFromToken(token);
+        checkFeatureFlags(token);
+        checkFlagValues(token);

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@kinde-core/src/main/java/com/kinde/token/HardCheckExample.java` around lines
36 - 42, The code unnecessarily re-parses a KindeToken:
session.retrieveTokens().getAccessToken() already returns a KindeToken, yet the
code calls client.tokenFactory().parse(token.token()); either remove the
redundant parse and use the retrieved KindeToken (token) for the validity check,
or if the parse() call is intentional to demonstrate the API, add a concise
comment above the parse line explaining that you are intentionally demonstrating
tokenFactory.parse(String) and why (e.g., converting raw token string into a
validated KindeToken); update references to parsedToken or token accordingly
(symbols: KindeClientSession, retrieveTokens, getAccessToken, KindeToken,
KindeTokenFactory, parse, token()).

---

109-121: Remove unnecessary try-catch blocks.

The methods isFeatureFlagEnabled() and getFeatureFlagValue() do not throw exceptions when a flag is not found. They return false and null respectively, with all exceptions handled internally. The try-catch blocks are ineffective and should be removed in favor of checking return values directly:

boolean darkMode = token.isFeatureFlagEnabled("dark_mode");
if (!darkMode) {
    log.info("dark_mode: not found or disabled in token");
} else {
    log.info("dark_mode enabled: {}", darkMode);
}

Object betaValue = token.getFeatureFlagValue("beta_features");
if (betaValue == null) {
    log.info("beta_features: not found in token");
} else {
    log.info("beta_features value: {}", betaValue);
}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@kinde-core/src/main/java/com/kinde/token/HardCheckExample.java` around lines
109 - 121, Remove the unnecessary try-catch blocks around
token.isFeatureFlagEnabled("dark_mode") and
token.getFeatureFlagValue("beta_features") in HardCheckExample; these methods
don’t throw for missing flags, so call isFeatureFlagEnabled() and check the
boolean, and call getFeatureFlagValue() and check for null, then log appropriate
messages (e.g. use log.info rather than System.out: "dark_mode: not found or
disabled in token" when false, "dark_mode enabled: {}" when true; and
"beta_features: not found in token" when null, "beta_features value: {}" when
non-null).

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In `@kinde-core/src/main/java/com/kinde/token/HardCheckExample.java`:
- Around line 36-42: The code unnecessarily re-parses a KindeToken:
session.retrieveTokens().getAccessToken() already returns a KindeToken, yet the
code calls client.tokenFactory().parse(token.token()); either remove the
redundant parse and use the retrieved KindeToken (token) for the validity check,
or if the parse() call is intentional to demonstrate the API, add a concise
comment above the parse line explaining that you are intentionally demonstrating
tokenFactory.parse(String) and why (e.g., converting raw token string into a
validated KindeToken); update references to parsedToken or token accordingly
(symbols: KindeClientSession, retrieveTokens, getAccessToken, KindeToken,
KindeTokenFactory, parse, token()).
- Around line 109-121: Remove the unnecessary try-catch blocks around
token.isFeatureFlagEnabled("dark_mode") and
token.getFeatureFlagValue("beta_features") in HardCheckExample; these methods
don’t throw for missing flags, so call isFeatureFlagEnabled() and check the
boolean, and call getFeatureFlagValue() and check for null, then log appropriate
messages (e.g. use log.info rather than System.out: "dark_mode: not found or
disabled in token" when false, "dark_mode enabled: {}" when true; and
"beta_features: not found in token" when null, "beta_features value: {}" when
non-null).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 6ba8d173-7a13-4db1-bd18-96154b7e4c18

📥 Commits

Reviewing files that changed from the base of the PR and between f99053f and cb57b7b.

📒 Files selected for processing (2)

• kinde-core/pom.xml
• kinde-core/src/main/java/com/kinde/token/HardCheckExample.java

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!