Hi, im having this issue when trying to call duoClient.exchangeAuthorizationCodeFor2FAResult
Caused by: java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.ObjectMapper.readerFor(Lcom/fasterxml/jackson/databind/JavaType;)Lcom/fasterxml/jackson/databind/ObjectReader;

Googling i found that the readerFor method was introduced in version 2.6 of fasterxml

Is there a way to update the fasterxml dependency or am i going in the wrong way?
Thnx

Just tried duo-example and it looks like it works but then it just shows me the login screen like this:

From glancing at the code it looks like it's supposed to dump token data.

Am I doing something wrong or what?

If you want to support Java 16 and onward, you will need to update Lombok to 1.18.20:

projectlombok/lombok#2681 (comment)

The current version of duo_universal_java (1.1.3) is using OkHttp 3.14.9 under the hood. This version of OkHttp has a known issue with Tomcat applications where its internal thread pool cannot be shut down cleanly because it does not provide an API to signal OkHttp to shut them down. This was supposedly fixed in version 4.3.

We have been mandated to Duo as our corporate MFA solution, which we have successfully implemented and deployed to production. However, we are now seeing evidence of the OkHttp thread pool issue in our server logs:

03-Aug-2023 06:38:26.643 WARNING [Thread-290707] org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The web application [XXXXXXX] appears to have started a thread named [OkHttp ConnectionPool] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread:
 [email protected]/java.lang.Object.wait(Native Method)
 [email protected]/java.lang.Object.wait(Object.java:462)
 okhttp3.internal.connection.RealConnectionPool.lambda$new$0(RealConnectionPool.java:62)
 okhttp3.internal.connection.RealConnectionPool$$Lambda$1771/0x00000008002bd440.run(Unknown Source)
 [email protected]/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
 [email protected]/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
 [email protected]/java.lang.Thread.run(Thread.java:829)

This isn't causing any critical issues for our apps, but it is a nuisance when we need to shutdown or restart an app.

Please investigate updating the OkHttp dependency to 4.3 or later to resolve this issue.

Why does the client now default to use_duo_code_attribute=true and hence the authorisation code parameter becomes duo_code over the previous OAuth2.0 standard code name?

The maven artifact described in the documentation (https://duo.com/docs/duoweb-v4#add-the-duo-universal-dependency-to-your-project) is wrong. It needs to reference the duo-universal-sdk not duo-universal-java artifact - there is also no version 1.0.0 on maven central.

In v1.1.3 the okhttp3 logging-interceptor changed to v4.9.1 which depends on okhttp v4.9.1. However, retrofit v2.9.0 is still at okhttp v3.14.9. It seems to all work, but maybe the logging-interceptor should be held back a version?

Hello,

how can I get support for http proxy?
I did not find another way than having code changes in the sdk modul to get OkHttp to use proxy.

Thank you

Benjamin

Hello, I'm facing trouble of Bad Request while exchanging the authorization code to token one.
I have reproduced this problem by changing time on my local machine.

Could be something wrong in time while signing of token ?

thanks

Your prompt reply would be appreciated

Line 338 of the Client class e.g.

String idToken = response.getId_token();

Causes an NPE if (in the unlikely event) the auth code is invalid or not present. The Token endpoint correctly returns an HTTP 400, so I think the logic just needs to check the response is actually present and correct before trying to access the id_token.

Hi ,
Wat value should i give duo.redirect.uri =? here as i am not able to find this field value

Detailed Description

Ideally this SDK would be as lightweight (i.e. dependency-free) as possible. The Lombok dependency does make the data structures a little cleaner but might not be worth it overall

Use Case

Remove dependencies that are not absolutely critical to the SDK operation.

Workarounds

N/A

Possible Problems

If we hand-create the getters and setters that Lombok was generating for us, we need to either
A) make sure we name them exactly the same
or, if we change the names
B) update the callers as well AND remember that people may be making calls from their own code - thus this could be a backwards-incompatible change