Closed toniwe closed 4 months ago
@toniwe I can confirm that commit introduced the bug. Since we're using zeebe and operate, using 8.4.0.7 was not an option for us (due to changes in java-common) so I did a test in our project: ->
Now it works as expected and I am able to perform operations on the client
I've opened a pull request here
Hi @toniwe, @jancalvef,
Many thanks for your issue and contribution. I'm currently reviewing it. I'll keep you posted today.
Hi @toniwe, @jancalvef,
I've merged Jan Christian PR and released it in 8.5.3.1. I'll let you close the issue or update it if the problem is not yet solved.
Thanks again :)
I've just spotted an issue with date filters and have released a 8.5.3.1 patched version.
In the tasklist client 8.5.0 I currently can not get authentication using bearer tokens to work properly. Although the client is configured and built correctly, I always get responses with 401 status code, because not authentication header is ever sent.
Caused by: io.camunda.tasklist.generated.invoker.ApiException: searchTasks call failed with: 401 - {"message":"Full authentication is required to access this resource"} at io.camunda.tasklist.generated.api.TaskApi.getApiException(TaskApi.java:82) at io.camunda.tasklist.generated.api.TaskApi.searchTasksWithHttpInfo(TaskApi.java:521) at io.camunda.tasklist.generated.api.TaskApi.searchTasks(TaskApi.java:499) at io.camunda.tasklist.CamundaTaskListClient.getTasks(CamundaTaskListClient.java:479) ... 41 common frames omitted
I think the main problem is the removal of the
TaskApi
's re-initialization with the changed ApiClient in this commit (though I have not tested it).It seems the TaskApi doesn't hold a reference to the
ApiClient
directly but rather reads ApiClient's request interceptor value just once in the cunstructor. This seems to be important for both building the client initially and when refreshing the token inreconnectEventually
.using Camunda 8.5.0 self managed; using the previous version of camunda-tasklist-client-java (8.4.0.7) works as a workaround.
Could you please share the piece of code for Self Managed Authentication? I'm getting the following error:
java.lang.NullPointerException: null
at java.base/java.util.Objects.requireNonNull(Objects.java:220) ~[na:na]
at org.ehcache.core.EhcacheBase.checkNonNull(EhcacheBase.java:611) ~[ehcache-3.10.8.jar:3.10.8]
at org.ehcache.core.EhcacheBase.containsKey(EhcacheBase.java:216) ~[ehcache-3.10.8.jar:3.10.8]
at io.camunda.identity.sdk.authentication.AbstractAuthentication.requestToken(AbstractAuthentication.java:90) ~[identity-sdk-8.5.0.jar:8.5.0]
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[na:na]
at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[na:na]
at io.camunda.identity.sdk.annotation.AnnotationProcessor.lambda$apply$0(AnnotationProcessor.java:33) ~[identity-sdk-8.5.0.jar:8.5.0]
at jdk.proxy2/jdk.proxy2.$Proxy70.requestToken(Unknown Source) ~[na:na]
at io.camunda.common.auth.SelfManagedAuthentication.getIdentityToken(SelfManagedAuthentication.java:31) ~[java-common-8.5.3.jar:8.5.3]
at io.camunda.common.auth.SelfManagedAuthentication.generateToken(SelfManagedAuthentication.java:23) ~[java-common-8.5.3.jar:8.5.3]
at io.camunda.common.auth.JwtAuthentication.getTokenHeader(JwtAuthentication.java:30) ~[java-common-8.5.3.jar:8.5.3]
at io.camunda.tasklist.CamundaTaskListClient.authenticate(CamundaTaskListClient.java:534) ~[camunda-tasklist-client-java-8.5.3.1.jar:na]
at io.camunda.tasklist.CamundaTaskListClient.<init>(CamundaTaskListClient.java:65) ~[camunda-tasklist-client-java-8.5.3.1.jar:na]
at io.camunda.tasklist.CamundaTaskListClientBuilder.build(CamundaTaskListClientBuilder.java:76) ~[camunda-tasklist-client-java-8.5.3.1.jar:na]
The piece of code that I'm using to create a client:
CamundaTaskListClient client = CamundaTaskListClient.builder()
.taskListUrl("http://localhost:8082")
.selfManagedAuthentication(
"client-id-here",
"client-secret-here",
"http://localhost:8084"
)
.build();
Hi @hedza06,
That's not related to the issue. But you should point to keycloak and not identity in the 3rd parameter of the SM auth
Hey @hedza06 , @chDame , I'm also facing the same issue while authenticating TaskList client for selfManaged authentication clientId and clientSecret I'm using of tasklist
The code used for creating client : CamundaTaskListClient clientT = CamundaTaskListClient.builder() .taskListUrl("http://localhost:8082") .selfManagedAuthentication("tasklist", "tasklist-client-secret","http://localhost:18080/auth/realms/camunda-platform/protocol/openid-connect/token" ) .build(); logger.info("Tasklist client created: {}", clientT);
I'm getting the same error
java.lang.NullPointerException: null
at java.base/java.util.Objects.requireNonNull(Objects.java:233) ~[na:na]
at org.ehcache.core.EhcacheBase.checkNonNull(EhcacheBase.java:611) ~[ehcache-3.10.8.jar:3.10.8]
at org.ehcache.core.EhcacheBase.containsKey(EhcacheBase.java:216) ~[ehcache-3.10.8.jar:3.10.8]
at io.camunda.identity.sdk.authentication.AbstractAuthentication.requestToken(AbstractAuthentication.java:90) ~[identity-sdk-8.5.1.jar:8.5.1]
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[na:na]
at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[na:na]
at io.camunda.identity.sdk.annotation.AnnotationProcessor.lambda$apply$0(AnnotationProcessor.java:33) ~[identity-sdk-8.5.1.jar:8.5.1]
at jdk.proxy2/jdk.proxy2.$Proxy75.requestToken(Unknown Source) ~[na:na]
at io.camunda.common.auth.SelfManagedAuthentication.getIdentityToken(SelfManagedAuthentication.java:31) ~[java-common-8.5.3.jar:8.5.3]
at io.camunda.common.auth.SelfManagedAuthentication.generateToken(SelfManagedAuthentication.java:23) ~[java-common-8.5.3.jar:8.5.3]
at io.camunda.common.auth.JwtAuthentication.getTokenHeader(JwtAuthentication.java:30) ~[java-common-8.5.3.jar:8.5.3]
at io.camunda.tasklist.CamundaTaskListClient.authenticate(CamundaTaskListClient.java:534) ~[camunda-tasklist-client-java-8.5.3.1.jar:na]
at io.camunda.tasklist.CamundaTaskListClient.
Hi @mukeshBethi,
Would you mind trying with http://localhost:18080/auth/realms/camunda-platform and http://localhost:18080/auth ? The authentication is managed using the identity SDK from Camunda. IMHO, that part is not sufficiently documented. I'll try it myself this morning. If there is an issue with the identity SDK, I'll revert to the "home made" SelfManagedAuthentication as it was earlier. And I'll keep you posted
Hey @chDame I have tried the above URL's and still it's showing the same issue just let me know if you find any lead Thank you.
Hi @mukeshBethi, @hedza06,
It seems there is a bigger issue there. Adding an audience in the selfManagedAuthentication solves the NullPointer but requests are failing right after. I'm digging into it.
8.5.3.2 is on its way and should solve the issue. Audience is now used for identity sdk for some caching operations. Audience was not provided as part of SM until now
Hi @toniwe, @jancalvef,
I've merged Jan Christian PR and released it in 8.5.3.1. I'll let you close the issue or update it if the problem is not yet solved.
Thanks again :)
hi @chDame, I don't think only creating the apis initially is enough, I am still getting the same errors after the first token is expired. As I wrote initially, the generated Apis don't keep the reference to the apiClient object so they are basically always just re-using the request-interceptor that was set first.
I created a quick PR for this, could you have a look? #93 - this also recreates the apis on reconnectEventually
Hi @toniwe,
Seems good to me. I'll merge it and release a 8.5.3.3 today. I'll keep you posted.
Hi @toniwe,
8.5.3.3 has been released. Would you mind testing and telling me if that solves the issue?
thanks @chDame, I tested it and it looks fine now!
In the tasklist client 8.5.0 I currently can not get authentication using bearer tokens to work properly. Although the client is configured and built correctly, I always get responses with 401 status code, because not authentication header is ever sent.
I think the main problem is the removal of the
TaskApi
's re-initialization with the changed ApiClient in this commit (though I have not tested it).It seems the TaskApi doesn't hold a reference to the
ApiClient
directly but rather reads ApiClient's request interceptor value just once in the cunstructor. This seems to be important for both building the client initially and when refreshing the token inreconnectEventually
.using Camunda 8.5.0 self managed; using the previous version of camunda-tasklist-client-java (8.4.0.7) works as a workaround.