Hello,
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-modeler, flowable-admin, flowable-task, 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
Create 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.
Hello Paul,
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?
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 flowable-ui-app.properties file
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.
@joram
I can confirm that I don’t see this issue if I create a separate database each for each of the UI applications:
flowable-idm: flowableidm
flowable-modeler: flowablemodeler
flowable-engine: flowable
flowable-admin: flowableadmin
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.
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.