-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Incorporate Modeler Custom Root Cert Code #139
Comments
For a unit test, start a dummy REST server and a dummy gRPC server - both using a self-signed certificate - and exercise one of the REST clients and the Zeebe gRPC client against them. |
This requires some rewiring. Reading the system certificate chain makes the constructor of the API clients async. We can't rely that the client is ready to roll after creating an instance. To get around this, I tried adding a static asynchronous All methods that actually use the REST or gRPC connection, however, are already asynchronous. So: I will put the network connection in an async context in the constructor, and await it in the API methods. So |
Looks like the gRPC server mock doesn't bind to localhost correctly in the GitHub CI environment? The tests pass locally, but not there. Maybe there is something running on that port in the runner? |
* feat(repo): load system certs when custom cert specified fixes #139 * fix(oauth): throw if cacheDir not writeable on Windows * test(oauth): make cache dir read-only on Windows * test(oauth): make cache dir deleteable on Windows * test(oauth): make token cache dir read-only on Windows * test(oauth): hack around Windows test not throwing * refactor(repo): test self-signed certificate support fixes #139 fixes #141 * test(repo): isolate unit tests and do not run in integration envs * test(repo): run unit tests on Windows runner in CI * feat(zeebe): update gRPC package dep version * ci(repo): run unit tests on Windows for PRs * ci(repo): use cross-env to support Windows runner in CI * test(oauth): use execSync for Windows commands * refactor(repo): use win-ca for Windows system certificates * refactor(repo): refactor code to use win-ca on Windows * refactor(oauth): debug log in CI * revert(oauth): remove certificate debug statement
## [8.5.1](v8.5.0...v8.5.1) (2024-05-05) ### Features * **repo:** load system certs when custom cert specified ([#144](#144)) ([8a47d5e](8a47d5e)), closes [#131](#131) [#131](#131) [#131](#131) [#135](#135) [#125](#125) [#125](#125) [#125](#125) [#125](#125) [#125](#125) [#125](#125) [#138](#138) [#136](#136) [#136](#136) [#136](#136) [#139](#139) [#139](#139) [#141](#141) [#139](#139) [#139](#139) [#141](#141) [#139](#139) [#139](#139) [#141](#141)
## [8.5.1](v8.5.0...v8.5.1) (2024-05-05) ### Features * **repo:** load system certs when custom cert specified ([#144](#144)) ([8a47d5e](8a47d5e)), closes [#131](#131) [#131](#131) [#131](#131) [#135](#135) [#125](#125) [#125](#125) [#125](#125) [#125](#125) [#125](#125) [#125](#125) [#138](#138) [#136](#136) [#136](#136) [#136](#136) [#139](#139) [#139](#139) [#141](#141) [#139](#139) [#139](#139) [#141](#141) [#139](#139) [#139](#139) [#141](#141)
At the moment, a user can specify a custom root certificate to use when their Camunda 8 installation is secured by a self-signed or other custom certificate.
The custom root certificate replaces the existing certificate store, rather than being added to it. The Desktop Modeler team have written OS-portable code that loads the existing certificate store and adds the custom certificate to use an aggregrate.
I am going to incorporate this code into the SDK, so that users do not need to write this.
The text was updated successfully, but these errors were encountered: