In a fresh installation of Flowable v6.1.2, it appears that I am unable to login to the UI applications with the default admin credentials of admin/test.
Here is what I do to deploy the Flowable wars in Tomcat:
- Copy the wars into Tomcat’s web app folder
- Edit the
flowable-ui-app.properties of the UI applications
flowable-admin to use MySQL database instead of the default H2.
- Edit db.properties of
flowable-rest to have the MySQL information/credentials.
- Edit the re-direct URLs to have the right host information
flowable database with all required privileges and credentials as per the properties files.
- Restart Tomcat.
ACT_ID_USER table does have 3 users by default: kermit, fozzie, gonzo and none of them work.
A note here that the issue does not exist if I leave the default H2 database configuration as it is.
There will be some error in the tomcat logs that might give clues.
What’s the expectation with regards to the user creation for flowable-ui when using MySQL db - should the admin/test credential be created in the ACT_ID_USER table?
Does flowable-ui use ACT_ID_USER table for authentication or does it rely on the configuration files?
According to the docs:
“When the Flowable IDM application is deployed and started, it will check if there’s a user available in the ACT_ID_USER table, and if not it will use the admin.userid property to create a new default admin user in this table. It will also add all available privileges in the Flowable project to the newly created admin user”
I don’t see anything outwardly suspicious from the logs in the locations where users/groups are initialised.
07:52:29,601 [Thread-5] INFO org.flowable.engine.impl.asyncexecutor.AcquireAsyncJobsDueRunnable - starting to acquire async jobs due 07:52:29,608 [Thread-7] INFO org.flowable.engine.impl.asyncexecutor.ResetExpiredJobsRunnable - starting to reset expired jobs 07:52:29,609 [Thread-6] INFO org.flowable.engine.impl.asyncexecutor.AcquireTimerJobsRunnable - starting to acquire async jobs due 07:52:29,690 [localhost-startStop-1] INFO org.flowable.engine.impl.cmd.ValidateV5EntitiesCmd - Total of v5 deployments found: 0 07:52:29,728 [localhost-startStop-1] INFO org.flowable.rest.conf.DemoDataConfiguration - Initializing demo groups 07:52:29,747 [localhost-startStop-1] INFO org.flowable.rest.conf.DemoDataConfiguration - Initializing demo users 07:52:29,824 [localhost-startStop-1] INFO org.flowable.rest.conf.DemoDataConfiguration - Initializing demo process definitions 07:52:29,828 [localhost-startStop-1] INFO org.flowable.rest.conf.DemoDataConfiguration - Initializing demo models 07:52:30,450 [localhost-startStop-1] INFO org.springframework.security.web.DefaultSecurityFilterChain - Creating filter chain: org.springframework.security.web.util.matcher.AnyRequestMatcher@1, [org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter@1660988f, org.springframework.security.web.context.SecurityContextPersistenceFilter@695794f5, org.springframework.security.web.header.HeaderWriterFilter@791e73c3, org.springframework.security.web.authentication.logout.LogoutFilter@4192ac3b, org.springframework.security.web.authentication.www.BasicAuthenticationFilter@7f4b24e4, org.springframework.security.web.savedrequest.RequestCacheAwareFilter@4a8bf094, org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter@7f5f701e, org.springframework.security.web.authentication.AnonymousAuthenticationFilter@7ec72ef7, org.springframework.security.web.session.SessionManagementFilter@8dcadac, org.springframework.security.web.access.ExceptionTranslationFilter@46f32bdf, org.springframework.security.web.access.intercept.FilterSecurityInterceptor@45964ea5]
I have exactly the same problem. Authentication fails for all UI apps, but the basic authentication for the rest engine works. Deployed on JBoss EAP7 + Oracle RDBMS
@jeroen-de-schutter : hmm, seems like something is wrong somewhere … too many people having the same problem.
Could you write down the steps (don’t need to be very detailed) that you’ve done so we can try to reproduce?
- Ran the Oracle DDL scripts
- Merged all
flowable-ui-app.properties files into one single file and put it in a jBoss module
- Pointed to a JNDI datasource in the
flowable-ui-app.properties file for the Oracle database connection
- Modified the
jboss-deployment-structure.xml file for each flowable webapp and added dependency to the module containing the
- Deployed flowable-rest, flowable-admin and flowable-idm wars on JBoss EAP7 server
Basic authentication for the REST services works.
When I use the login form on the flowable-idm webapp, I get “invalid credetials”, but a row is added to the
ACT_ID_TOKEN table anyway. So both the authentication and the database connection seem OK.
I can confirm that I don’t see this issue if I create a separate database each for each of the UI applications:
I have an (untested) theory that the problem is that both the flowable-rest and flowable-idm runs in the same database, and flowable-rest bootstraps itself first.
Flowable-rest sets up its users here - https://github.com/flowable/flowable-engine/blob/flowable-6.1.2/modules/flowable-app-rest/src/main/java/org/flowable/rest/conf/DemoDataConfiguration.java
and flowable-idm sets up its users here - https://github.com/flowable/flowable-engine/blob/flowable-6.1.2/modules/flowable-ui-idm/flowable-ui-idm-conf/src/main/java/org/flowable/app/conf/Bootstrapper.java
If the flowable-rest configuration runs first, there will be Kermit, gonzo, fozzie setup without any related privileges to task/modeler/idm/admin app. Then when the flowable-idm app is run the first thing it does is check if any users exists. Because 3 already exist the flowable-idm setup is skipped.
To test if this theory is correct, try emptying the database, and deploying flowable-idm first and flowable-rest afterwards.
Alternatively, configure flowable-rest to not have any demo data.
Your theory is correct @pstapleton !
Just tested it :
- shutdown all running flowable applications
- dropped the idm database tables
- restarted the idm and admin application
- logged in to the admin application with credentials admin/test
- restarted the rest application, muppet users are added to the ACT_ID_USER, was able to log in with the kermit user
Should I add this as a bug on the issue tracker ?
@pstapleton: indeed, good thinking. Thanks!
@jeroen-de-schutter : yes, thanks! Probably the easiest fix is to have the rest app also check for existing users wrt creating the demo test data.
Is this bug fix available in Flowable 6.4.