Token is always expired from cache #163
Assignees
Labels
bug
Something isn't working as intended
Comments
jwulf
added a commit
that referenced
this issue
May 22, 2024
Merged
github-actions bot
pushed a commit
that referenced
this issue
May 22, 2024
## [8.5.4-alpha.2](v8.5.4-alpha.1...v8.5.4-alpha.2) (2024-05-22) ### Bug Fixes * **issue137:** support ZEEBE_REST_ADDRESS and ZEEBE_GRPC_ADDRESS environment variables ([#159](#159)) ([41fdca0](41fdca0)) * **oauth:** correctly expire cached token ([#164](#164)) ([c86e550](c86e550)), closes [#163](#163) ### Features * **zeebe:** support Zeebe User Task REST API ([022607b](022607b)), closes [#34](#34)
github-actions bot
pushed a commit
that referenced
this issue
May 22, 2024
## [8.5.4-alpha.2](v8.5.4-alpha.1...v8.5.4-alpha.2) (2024-05-22) ### Bug Fixes * **issue137:** support ZEEBE_REST_ADDRESS and ZEEBE_GRPC_ADDRESS environment variables ([#159](#159)) ([41fdca0](41fdca0)) * **oauth:** correctly expire cached token ([#164](#164)) ([c86e550](c86e550)), closes [#163](#163) ### Features * **zeebe:** support Zeebe User Task REST API ([022607b](022607b)), closes [#34](#34)
github-actions bot
pushed a commit
that referenced
this issue
May 24, 2024
## [8.5.4](v8.5.3...v8.5.4) (2024-05-24) ### Bug Fixes * **issue137:** support ZEEBE_REST_ADDRESS and ZEEBE_GRPC_ADDRESS environment variables ([#159](#159)) ([41fdca0](41fdca0)) * **oauth:** correctly expire cached token ([#164](#164)) ([c86e550](c86e550)), closes [#163](#163) ### Features * **camunda8:** support Basic Auth ([d6acdfd](d6acdfd)), closes [#165](#165) * **oauth:** add conditional loading of client key and cert for getting a token ([#161](#161)) ([f05aa8a](f05aa8a)) * **zeebe:** support Zeebe User Task REST API ([022607b](022607b)), closes [#34](#34)
github-actions bot
pushed a commit
that referenced
this issue
May 24, 2024
## [8.5.4](v8.5.3...v8.5.4) (2024-05-24) ### Bug Fixes * **issue137:** support ZEEBE_REST_ADDRESS and ZEEBE_GRPC_ADDRESS environment variables ([#159](#159)) ([41fdca0](41fdca0)) * **oauth:** correctly expire cached token ([#164](#164)) ([c86e550](c86e550)), closes [#163](#163) ### Features * **camunda8:** support Basic Auth ([d6acdfd](d6acdfd)), closes [#165](#165) * **oauth:** add conditional loading of client key and cert for getting a token ([#161](#161)) ([f05aa8a](f05aa8a)) * **zeebe:** support Zeebe User Task REST API ([022607b](022607b)), closes [#34](#34)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I just found a bug in the authentication token caching code that will impact resource usage. (This could be a contributor to #53 )
The OAuthProvider component was comparing seconds since Unix epoch from the decoded JWT against milliseconds since Unix epoch from the JS Date object, and always expiring the token and requesting a new one with every API request.
This will have been causing higher resource requirements for applications connecting using the JS SDK.
This error did not show up in the unit tests because the library that I am using to construct my dummy token specifies the ttl in milliseconds. The SaaS JWT is in seconds.
I’ve replaced the library in the unit tests, fixed the token cache expiry logic, and I’ll push an updated package shortly.
The text was updated successfully, but these errors were encountered: