Embedded Camunda Web App Issues


#1

We’ve embedded the Camunda web apps inside our Spring Boot microservice, and we can access the web apps by browsing to the microservice endpoint in a browser; we are currently using an in-memory H2 database for Camunda.

We have added the following maven dependencies to our microservice pom.xml, and are using Camunda v7.9.0 (bom version 3.0).

    <dependency>
        <groupId>org.camunda.bpm.springboot</groupId>
        <artifactId>camunda-bpm-spring-boot-starter</artifactId>
        <version>${camunda.version}</version>
    </dependency>

    <dependency>
        <groupId>org.camunda.bpm.springboot</groupId>
        <artifactId>camunda-bpm-spring-boot-starter-webapp</artifactId>
        <version>${camunda.version}</version>
    </dependency>

and the following dependency management entry:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.camunda.bpm</groupId>
            <artifactId>camunda-bom</artifactId>
            <version>${camunda.bom.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Each of the apps (Cockpit, Tasklist and Admin) return pages OK to the browser, and there aren’t any errors in the microservice logs, however they seem to be behaving oddly (with the exception of Cockpit that seems to work without any issues).

The odd things I have noticed are as follows:

  1. Tasklist doesn’t show any tasks at all, despite Cockpit showing that processes are active and tasks are present
  2. Tasklist doesn’t show any filters, and adding filters still does not show any tasks
  3. Only a few of the Admin functions are showing and available, namely only options:
  • My Profile
  • Manage Authorizations
  • General
  • Execution Metrics

Other actions such as Create New User, Create New Tenant, etc. aren’t shown as links on the dashboard.

There is one user that exists, created as a result of the embedded Camunda starting up, and this is a user created via the following YAML configuration in bootstrap.yml:

  camunda.bpm:
    webapp:
      index-redirect-enabled: true
    admin-user:
      id: camunda
      password: password

This “Camunda” user details as shown in the Camunda UI show it as a user in the “camunda-admin” group.

Does anyone have any idea why the Admin and Tasklist web apps do not seem to be working properly, and if there’s anything I can check to correct this issue?

Thanks Steve


#2

One step forwards, I noticed there was an additional config property related to creating an initial Filter to show all tasks on H2, so I have added that and it now shows the tasks correctly in TaskList (the “filter:” setting):

camunda.bpm:
  webapp:
    index-redirect-enabled: true
  admin-user:
    id: camunda
    password: password
  filter:
    create: All Tasks

Still not able to create new users, but will try against a non-H2 db tomorrow…


#3

Using Postgres instead of H2 didn’t solve the issue of not being able to create new users and perform other admin tasks.

Anyone have any ideas? Thanks

UPDATE:

If I execute the REST API against the microservice, it returns the user OK, but when I query for the Aurhorizations that the user has it returns an empty array, hence I guess why I can’t access most of the functions in the Admin module.

My microservice is hosted on port 11004, and the REST endpoint is configured to be “camunda-rest”.

spring:
  jersey:
    application-path: /camunda-rest

GET http://localhost:11004/camunda-rest/user
[
    {
        "id": "camunda",
        "firstName": "Camunda",
        "lastName": "Camunda",
        "email": "camunda@localhost"
    }
]

GET http://localhost:11004/camunda-rest/authorization?userIdIn=camunda
[]

Given that this user was created automatically by the starter webapp maven module (as described previously) does this indicate that there is an issue with the auto user creation process of Camunda itself?


#4

Have you enabled authorizations? I seem to recall the default is disabled in the engine. See also https://docs.camunda.org/manual/latest/user-guide/spring-boot-integration/configuration/#camunda-engine-properties
Search for the camunda.bpm.authorization part. It defaults to the engine’s settings.


#5

Hi. Thanks for the suggestion! however I have tried adding the following to the “camunda.bpm” section and it still exhibits the same issue.

  authorization:
    enabled: true

#6

I assume the configuration you have only creates the user, but no authorizations. It might also be a thing now with initial creation vs re-run, since you’ve tried out things before. Sounds like something a real Camundo could probably answer more accurately for you :slight_smile:


#7

Yes, it’s very weird.

It is almost like the authorizations part is there, but that the admin user created is disconnected from the “camunda-admin” group. When I run the service mentioned above to list auths for the “camunda” user it created, it returns an empty list. If I go into the “Manage Authorizations” forms (that I can see and access) and add authorizations directly against the user these then come back in the service call. I’ve added ALL auths for the user into all possible areas, and they are all returned then in the array from the service call, but I still cannot do anything more in terms of permissions in the UI.

So, it does sound like authorizations are turned off at some level like you said…


#8

I’m not quite sure how the webapp functions within Spring Boot. I know from our case we had to enable the authorizations in the engine of the webapp too because that’s the one used in the webapp if you run it standalone. Our issue there was that we were overriding the webapp’s XML config and repackaging it, thereby overriding some of the default configuration. I don’t know if the webapp uses the same engine as the Spring Boot application if you run it that way. But if not, authorizations need to be explicitly enabled there as well.


#9

I’ve added the following (in addition to the yml properties) to our Spring Boot CamundaConfiguration class (that extends AbstractCamundaConfiguration).

It seems it doesn’t want to play with me! :frowning:

@Override
public void preInit(SpringProcessEngineConfiguration processEngineConfiguration) {

    processEngineConfiguration.setAuthorizationEnabled(true);
    processEngineConfiguration.setAuthorizationEnabledForCustomCode(true);

    super.preInit(processEngineConfiguration);

}

@Override
public void preInit(ProcessEngineConfigurationImpl processEngineConfiguration) {

    processEngineConfiguration.setAuthorizationEnabled(true);
    processEngineConfiguration.setAuthorizationEnabledForCustomCode(true);
    
    super.preInit(processEngineConfiguration);

}

@Override
public void postInit(SpringProcessEngineConfiguration springProcessEngineConfiguration) {

    springProcessEngineConfiguration.setAuthorizationEnabled(true);
    springProcessEngineConfiguration.setAuthorizationEnabledForCustomCode(true);

    JobExecutor jobExecutor = springProcessEngineConfiguration.getJobExecutor();
    jobExecutor.setMaxWait(maxWait);
    jobExecutor.setMaxJobsPerAcquisition(maxJobsPerAquisition);
    jobExecutor.setWaitTimeInMillis(waitTimeInMillis);

    log.debug("Auth Enabled? : {}", springProcessEngineConfiguration.isAuthorizationEnabled());

}

#10

There was a similar issue a while ago, which it seems was fixed, so you should be able to get it to work: https://github.com/camunda/camunda-bpm-spring-boot-starter/issues/118

Maybe @jangalinski can point you to the exact tweak you need :slight_smile:


#11

Oliver Steinhauer was the driving force there … I never really dug deep in the authorization stuff, so I guess I wont be of much help.


#12

Interestingly, this issue doesn’t seem to be one of Authorizations, or lack of permissions to actually be able to perform the tasks… If I enter the following URL into the browser after having logged in :

http://localhost:11004/app/admin/default/#/user-create

I get shown the Create User page and can happily create a new user… so it looks like it’s an issue with the URL’s that get built on the Admin dashboard (if that makes anyone think of a reason why that might be?)