Unable to login into cockpit in the hosted server

Hi,

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

spring.datasource.url=jdbc:sqlserver://xxxx
spring.datasource.driverClassName=com.microsoft.sqlserver.jdbc.SQLServerDriver
spring.datasource.username=xxx_user
spring.datasource.password=xxxx_pass
spring.h2.console.enabled=true
spring.jpa.show-sql=true
spring.jpa.properties.hibernate.dialect=org.hibernate.dialect.SQLServer2008Dialect
spring.jpa.properties.hibernate.ddl-auto=true
spring.jpa.properties.hibernate.hbm2ddl.auto=create-drop
spring.datasource.defaultTransactionIsolation=READ_COMMITTED

P.S: I’m able to access rest endpoints hosted on this workflow service but not able to login/authenticate the cockpit (Camunda UI)

Hello my friend!
Welcome to community \o/

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.

I hope this helps!

William Robert Alves

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:

Once again thank you so much for your reply!

Hi brother!
You are getting errors on these 2 endpoints… which still looks like authorization / authentication to me.

Have you tried running your project locally? It works?

Can you access the Camunda database? Is your user parameterized in the table?

William Robert Alves

Hi @WilliamR.Alves
Yes I have tried running the project locally with H2 database and it is working. I’m able to login into Camunda UI in my local.

Yes, I am able to access Camunda database and below is the default user admin. Would you help me to understand the parameterised user.

Here is my local camunda UI:

a question… on the server, do you run your application in docker / kubernetes?

Do you use a load balancer? If the answer is yes, scale your environment in just 1 pod to test.

William Robert Alves

1 Like

Thanks a lot. Yes, application running on k8s cluster and worked after limiting to single pod.

1 Like

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.

I’m happy to be able to help!

William Robert Alves

Just contextualizing in case you don’t have knowledge about sticky sessions…

This means that all requests made by the same user are always routed to the same server, regardless of how many pods you have running. :smile:

William Robert Alves

:laughing: 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. :handshake:

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.