Prepare 1.5.0 by nilsbehlen · Pull Request #84 · privacyidea/java-client

nilsbehlen · 2026-03-05T13:12:01Z

No description provided.

Copilot

Pull request overview

Prepares the privacyidea-java-client for the 1.5.0 release by extending challenge/passkey handling, adjusting client-mode based logic, improving async response body handling/logging, and bumping the Maven version.

Changes:

Update PIResponse challenge helpers (pushAvailable, otpMessage, hasChallenges) and customize Gson deserialization for Challenge.
Extend JSONParser to recognize passkey challenges inside multi_challenge.
Refactor OkHttp async response consumption to close ResponseBody and include HTTP status in logs; bump project version to 1.5.0.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 7 comments.

File	Description
`src/main/java/org/privacyidea/PIResponse.java`	Adds challenge helpers and new filtering logic; introduces a custom Gson deserializer for `Challenge`.
`src/main/java/org/privacyidea/JSONParser.java`	Adds handling for passkey challenges found in the `multi_challenge` array.
`src/main/java/org/privacyidea/AsyncRequestCallable.java`	Ensures response bodies are closed and adjusts logging behavior/format.
`pom.xml`	Bumps artifact version to `1.5.0` and changes test execution configuration.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-03-05T13:17:56Z

src/main/java/org/privacyidea/PIResponse.java

    public boolean pushAvailable()
    {
-        return multiChallenge.stream().anyMatch(c -> isPushOrSmartphoneContainer(c.getType()));
+        return multiChallenge.stream().anyMatch(c -> isPushOrSmartphoneContainer(c.getType()) && "poll".equals(c.getClientMode()));


pushAvailable() now requires clientMode to be exactly "poll". Many server responses don’t include client_mode per challenge (it parses as an empty string), so this can incorrectly return false even when a push challenge is present. Consider detecting push based on token type alone or falling back to the response’s preferredClientMode when clientMode is missing.

Suggested change

return multiChallenge.stream().anyMatch(c -> isPushOrSmartphoneContainer(c.getType()) && "poll".equals(c.getClientMode()));

if (multiChallenge == null || multiChallenge.isEmpty())

{

return false;

}

return multiChallenge.stream().anyMatch(c -> {

if (!isPushOrSmartphoneContainer(c.getType()))

{

return false;

}

String clientMode = c.getClientMode();

if (clientMode == null || clientMode.isEmpty())

{

// Fall back to the response's preferred client mode when per-challenge clientMode is missing

return "poll".equals(preferredClientMode);

}

return "poll".equals(clientMode);

});

Copilot · 2026-03-05T13:17:56Z

src/main/java/org/privacyidea/AsyncRequestCallable.java

+        // The body of the response can be in `body()` for success cases or in `errorBody()` for error cases.
+        // We need to handle both and ensure the body is closed to prevent resource leaks.
        // The body can only be consumed once.


The comment mentions errorBody(), but okhttp3.Response doesn’t have an errorBody() API (that’s Retrofit). This is misleading documentation; either adjust the comment to OkHttp semantics (body is available regardless of status) or implement the intended behavior in the appropriate layer.

Suggested change

// The body of the response can be in `body()` for success cases or in `errorBody()` for error cases.

// We need to handle both and ensure the body is closed to prevent resource leaks.

// The body can only be consumed once.

// For OkHttp, the response body is always available via `body()`, regardless of HTTP status.

// We must ensure the body is closed to prevent resource leaks, and it can only be consumed once.

// Using try-with-resources guarantees the body is properly closed after reading.

Copilot · 2026-03-05T13:17:57Z

src/main/java/org/privacyidea/AsyncRequestCallable.java

            {
                String s = responseBody.string();
-                if (!privacyIDEA.logExcludedEndpoints().contains(path) && !ENDPOINT_AUTH.equals(path))
+                if (!privacyIDEA.logExcludedEndpoints().contains(path))


This change will log the full response body for all endpoints not in logExcludedEndpoints(). Since /auth is not excluded by default (and returns JWT/token material), this can leak sensitive credentials into logs. Please re-add an explicit /auth exclusion (or add it to the default excluded list) and/or redact tokens before logging.

Suggested change

if (!privacyIDEA.logExcludedEndpoints().contains(path))

if (!privacyIDEA.logExcludedEndpoints().contains(path) && !ENDPOINT_AUTH.equals(path))

Copilot · 2026-03-05T13:17:57Z

pom.xml

+                    <skipTests>true</skipTests>
                </configuration>


Setting Surefire’s <skipTests> to true disables unit tests for all builds, which makes it easy to ship regressions (especially for a release bump). If the intent is only to speed up local packaging, consider removing this change or gating it behind a Maven profile / CI property instead of committing it as the default.

Copilot · 2026-03-05T13:17:57Z

src/main/java/org/privacyidea/PIResponse.java

+                                     .reduce("", (a, s) -> a + s + ", ")
+                                     .trim());
+
+        if (!sb.isEmpty())


StringBuilder in Java 14 (per pom.xml) does not have an isEmpty() method, so this will not compile. Use sb.length() > 0 (or check the appended string) before deleting the trailing separator.

Suggested change

if (!sb.isEmpty())

if (sb.length() > 0)

Copilot · 2026-03-05T13:17:58Z

src/main/java/org/privacyidea/PIResponse.java

+                                                String cm = c.getClientMode();
+                                                System.out.println(
+                                                        "challenge for " + c.getType() + " " + c.getSerial() + " with mode: " + cm);
+                                                boolean yes = "interactive".equals(cm);
+                                                return yes;


otpMessage() now filters challenges by clientMode == "interactive". In existing responses/fixtures, client_mode is often absent for OTP challenges (parsed as empty string), which would make otpMessage() return an empty message even when OTP challenges exist. Consider keeping the previous logic (exclude push/smartphone/webauthn) or falling back to preferredClientMode / treating missing client_mode as interactive for OTP challenges.

Suggested change

String cm = c.getClientMode();

System.out.println(

"challenge for " + c.getType() + " " + c.getSerial() + " with mode: " + cm);

boolean yes = "interactive".equals(cm);

return yes;

String clientMode = c.getClientMode();

String type = c.getType();

// If client_mode is explicitly "interactive", this is an OTP-style interactive challenge.

if ("interactive".equals(clientMode))

{

return true;

}

// For legacy responses where client_mode is missing or empty, fall back to the

// previous behavior: include all non-push / non-smartphone / non-webauthn challenges.

if (clientMode == null || clientMode.trim().isEmpty())

{

if (isPushOrSmartphoneContainer(type) || TOKEN_TYPE_WEBAUTHN.equals(type))

{

return false;

}

return true;

}

// Any other explicit client_mode is not considered an OTP-input challenge.

return false;

Copilot · 2026-03-05T13:17:58Z

src/main/java/org/privacyidea/PIResponse.java

+        return reduceChallengeMessagesWhere(c ->
+                                            {
+                                                String cm = c.getClientMode();
+                                                System.out.println(
+                                                        "challenge for " + c.getType() + " " + c.getSerial() + " with mode: " + cm);
+                                                boolean yes = "interactive".equals(cm);
+                                                return yes;
+                                            });


Library code should not write directly to stdout. The System.out.println(...) debug output in otpMessage() will spam application logs and may leak token/challenge details; please remove it or route it through the configured logger behind a debug flag.

Suggested change

return reduceChallengeMessagesWhere(c ->

{

String cm = c.getClientMode();

System.out.println(

"challenge for " + c.getType() + " " + c.getSerial() + " with mode: " + cm);

boolean yes = "interactive".equals(cm);

return yes;

});

return reduceChallengeMessagesWhere(c -> "interactive".equals(c.getClientMode()));

nilsbehlen added 2 commits October 20, 2025 12:51

small changes, prepare v1.5.0

125990d

v1.5.0

b9e6856

nilsbehlen requested a review from Copilot March 5, 2026 13:12

Merge branch 'master' into prepare-1.5.0

016bc8c

Copilot started reviewing on behalf of nilsbehlen March 5, 2026 13:12 View session

Copilot AI reviewed Mar 5, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Prepare 1.5.0#84

Prepare 1.5.0#84
nilsbehlen wants to merge 3 commits intomasterfrom
prepare-1.5.0

nilsbehlen commented Mar 5, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Copilot AI Mar 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-        return multiChallenge.stream().anyMatch(c -> isPushOrSmartphoneContainer(c.getType()) && "poll".equals(c.getClientMode()));
+        if (multiChallenge == null || multiChallenge.isEmpty())
+        {
+            return false;
+        }
+        return multiChallenge.stream().anyMatch(c -> {
+            if (!isPushOrSmartphoneContainer(c.getType()))
+            {
+                return false;
+            }
+            String clientMode = c.getClientMode();
+            if (clientMode == null || clientMode.isEmpty())
+            {
+                // Fall back to the response's preferred client mode when per-challenge clientMode is missing
+                return "poll".equals(preferredClientMode);
+            }
+            return "poll".equals(clientMode);
+        });

	if (!privacyIDEA.logExcludedEndpoints().contains(path))
	if (!privacyIDEA.logExcludedEndpoints().contains(path) && !ENDPOINT_AUTH.equals(path))

-                                                String cm = c.getClientMode();
-                                                System.out.println(
-                                                        "challenge for " + c.getType() + " " + c.getSerial() + " with mode: " + cm);
-                                                boolean yes = "interactive".equals(cm);
-                                                return yes;
+                                                String clientMode = c.getClientMode();
+                                                String type = c.getType();
+                                                // If client_mode is explicitly "interactive", this is an OTP-style interactive challenge.
+                                                if ("interactive".equals(clientMode))
+                                                {
+                                                    return true;
+                                                }
+                                                // For legacy responses where client_mode is missing or empty, fall back to the
+                                                // previous behavior: include all non-push / non-smartphone / non-webauthn challenges.
+                                                if (clientMode == null || clientMode.trim().isEmpty())
+                                                {
+                                                    if (isPushOrSmartphoneContainer(type) || TOKEN_TYPE_WEBAUTHN.equals(type))
+                                                    {
+                                                        return false;
+                                                    }
+                                                    return true;
+                                                }
+                                                // Any other explicit client_mode is not considered an OTP-input challenge.
+                                                return false;

Conversation

nilsbehlen commented Mar 5, 2026

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Mar 5, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants