I have configured Camunda in a Spring Boot application (To build a workflow service) and successfully logged into the cockpit on my local machine using the default credentials (admin/admin).
The localhost URL is: http://localhost:8080/camunda/app/welcome/default/#!/login. I am using the Spring Boot built-in H2 database, and below are the properties in the application.properties file:
spring.datasource.url=jdbc:h2:mem:testdb
spring.datasource.driverClassName=org.h2.Driver
spring.datasource.username=sa
spring.datasource.password=password
spring.h2.console.enabled=true
server.port=8080
camunda.bpm.database.schema-update=true
camunda.datasource.jdbc-url=jdbc:h2:mem:camunda
camunda.datasource.username=test
camunda.datasource.password=null camunda.bpm.admin-user.id=admin camunda.bpm.admin-user.password=admin
camunda.filter.create=All process instances
However, I have hosted the Spring Boot application on a development server with SQL Server as the database. I can see that all the necessary Camunda tables have been generated, similar to what happened with H2. However, I am encountering a ā403 Forbidden errorā when trying to log in to the application. I have attached a screenshot of the error, and below are the properties for my development server. Is this error related to Camunda configurations or does it have something to do with the configuration on the development server? Please suggest if I miss anything. Thank you in advance application.properties:
camunda.bpm.admin-user.id=admin
camunda.bpm.admin-user.password=admin
camunda.bpm.database.schema-name=ms_xxx
camunda.bpm.database.schema-update=true
camunda.bpm.database.table-prefix=ms_xxx.
camunda.bpm.filter.create=All tasks
camunda.bpm.logging.level=info
logging.level.org.springframework.security=INFO
logging.level.org.springframework.web=INFO
management.endpoint.health.show-details=always
This appears to be related to 2 problems, which may be related to the port and firewall configuration of the server your database is running on, or may be related to the security part of your application.
If your SQLServer is running on a machine other than Camunda, check the firewall rules to see if communication between both machines is being allowed. And make sure the communication port is correct, by default it is 1433 if Iām not mistaken, but this can be customized.
And as for the security part, you should probably be using spring security, or some security mechanism (I hope hehehe)⦠itās worth checking to make sure you donāt have any route blocking or something related that could be interfering and blocking the communication.
Thank you for your reply @WilliamR.Alves. This will assist me in my further investigation. Regarding the SQL Server port, yes, it is the default port 1433. I encountered the same ā403 Forbiddenā issue with the built-in H2 database on the development server. I have not yet enabled security features for this workflow service. Please see below server logs if that can give any clue.
GET /camunda/api/engine/engine HTTP/1.1: 200
GET /camunda/api/admin/auth/user/default HTTP/1.1: 404 Server logs:
2023-10-10 17:03:56,921 (traceId=a88d88f5b68993291509f0e109dd212e username=-) [app] WARN [http-nio-8080-exec-5] org.glassfish.jersey.server.wadl.WadlFeature: JAXBContext implementation could not be found. WADL feature is disabled.
2023-10-10 17:03:56,925 (traceId=null bytesSent=2748827 remoteIp=10.160.1.135 elapsedTime=141 referer=- userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-2] GET /camunda/app/cockpit/static/js/main.12f48097.chunk.js.map HTTP/1.1: 200
2023-10-10 17:03:57,098 (traceId=null bytesSent=20 remoteIp=10.160.1.135 elapsedTime=13 referer=http://appdev.dev.az.com/workflow-service/camunda/app/cockpit/default/ userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-1] GET /camunda/api/engine/engine HTTP/1.1: 200
2023-10-10 17:03:57,123 (traceId=null bytesSent=135 remoteIp=10.160.1.135 elapsedTime=11 referer=http://appdev.dev.az.com/workflow-service/camunda/app/cockpit/default/ userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-10] GET /camunda/api/admin/auth/user/default HTTP/1.1: 404
2023-10-10 17:03:57,178 (traceId=null bytesSent=- remoteIp=10.160.1.135 elapsedTime=3 referer=http:// appdev.dev.az. com/workflow-service/camunda/app/cockpit/styles/styles.css userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-6] GET /camunda/app/cockpit/fonts/IBMPlexSans-Italic.otf HTTP/1.1: 304
2023-10-10 17:03:57,216 (traceId=null bytesSent=7464065 remoteIp=10.160.1.135 elapsedTime=484 referer=- userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-8] GET /camunda/app/cockpit/static/js/2.2c955996.chunk.js.map HTTP/1.1: 200
2023-10-10 17:03:57,290 (traceId=null bytesSent=0 remoteIp=10.160.1.135 elapsedTime=466 referer=http:// appdev.dev.az. com/workflow-service/camunda/app/cockpit/default/ userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-5] GET /camunda/api/cockpit/plugin/cockpitPlugins/static/app/plugin.css HTTP/1.1: 200
2023-10-10 17:04:03,228 (traceId=null bytesSent=149 remoteIp=10.160.1.135 elapsedTime=9 referer=camunda/app/cockpit/default/ userAgent=āMozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36ā) [access] - [http-nio-8080-exec-4] POST /camunda/api/admin/auth/user/default/login/cockpit HTTP/1.1: 403
2023-10-10 17:07:04.304Z WARN c.a.m.o.e.i.p.TelemetryPipeline - In the last 5 minutes, the following operation has failed 4 times (out of 4): Sending telemetry to the ingestion service:
Thatās nice my friend @camundabeginner ! Then we discovered your problem.
Just remember that, limiting it to just one pod in k8s you will not have high availability of your application and will limit horizontal scalability, forcing you to scale vertically, and this has a limit.
The ideal is to keep more than one pod.
Try adjusting your load balancer to use sticky sessions for connections made to webapps. I believe it will solve your problem and you will be able to scale horizontally with more than one pod.
Thank you for bringing up the sticky sessions concern. I will address the sticky session issue, which we used to manage in the pre-stateless service era.
Your prompt response with potential solutions would be greatly appreciated.