Activiti Explorer creates several default users. One that I remember is username:kermit, password:kermit. This is an admin user and should be able to create additional users.
2012/12/9 Max Spring <m2spr...@springdot.org> > What do I need to do so I can log in to AE and assign user tasks to users? > -Max > > > > On 12/09/2012 07:09 AM, Kohsuke Kawaguchi wrote: > >> This was because I've removed the preliminary authentication integration >> (we were trouble-shooting why manual tasks newly created in Jenkow >> workflows don't show up in AE.) >> >> I think for the time being I'll go the federated route (where the >> authentication in AE needs to be set up separately but Jenkins will provide >> SSO) instead of taking over AE identity service. >> >> AE wants a lot of ability (such as being able to search an user, >> presumably so that you can assign tasks to them) that Jenkins doesn't >> provide in its abstraction. >> >> >> 2012/12/8 Max Spring <m2spr...@springdot.org <mailto: >> m2spr...@springdot.org**>> >> >> >> Done with merging the activiti-explorer branch to master. >> With the now separate Activiti Explorer plugin, I'm unable to login >> to AE. >> Even turned on security (Jenkins' own user database), AE doesn't let >> me in using same username/password as on the Jenkins side. >> -Max >> >> >> >> On 12/08/2012 05:49 PM, Max Spring wrote: >> >> I'm merging the activiti-explorer branch to master. >> These two artifactItems should not actually be in the POM any >> more, right? >> https://github.com/jenkinsci/_**_jenkow-plugin/blob/activiti-_** >> _explorer/jenkow-plugin/pom.__**xml#L206<https://github.com/jenkinsci/__jenkow-plugin/blob/activiti-__explorer/jenkow-plugin/pom.__xml#L206>< >> https://github.com/jenkinsci/**jenkow-plugin/blob/activiti-** >> explorer/jenkow-plugin/pom.**xml#L206<https://github.com/jenkinsci/jenkow-plugin/blob/activiti-explorer/jenkow-plugin/pom.xml#L206> >> > >> >> Thanks! >> -Max >> >> >> On 12/07/2012 07:02 PM, Kohsuke Kawaguchi wrote: >> >> >> As we discussed in IRC, I moved the activiti explorer part to >> a separate plugin and the activiti-explorer branch in the jenkow-plugin >> repository is now ready to be merged to the trunk. >> >> The merge is virtually conflict free, so I'll let you pick >> the timing to merge this back into the trunk. >> >> On 11/28/2012 12:01 PM, Kohsuke Kawaguchi wrote: >> >> >> This is mainly to Max, >> >> Over the Thanksgiving break, I hacked more on the Jenkow >> plugin (in the >> activiti-explorer branch.) >> >> I successfully embedded Activiti Explorer (AE) inside the >> plugin. You >> load the plugin, you hit http://localhost:8080/__** >> activiti-explorer/ <http://localhost:8080/__activiti-explorer/> < >> http://localhost:8080/**activiti-explorer/<http://localhost:8080/activiti-explorer/>> >> and >> >> you'll see AE embedded within. >> >> I've also created database-plugin [1,2] that defines a >> common >> abstraction for connecting database (more about this in a >> separate >> post.) I've used that in this branch to let the >> administrator configure >> the backend database for Activiti. >> >> Both the embedded AE and the activiti engine that the >> Jenkow plugin uses >> honor this configuration. >> >> I've also took a stub at integrating authentication >> between Jenkins and >> AE --- if you run AE stand-alone, you'll see that it asks >> you to login >> to the app. But in the embedded code, I alter the way AE >> wires the >> components to inject our own code that relies on Jenkins >> to do the >> authentication. So in effect it creates a single sign-on. >> >> The good thing about AE is that it has a contract >> interface for the >> identity/authentication service separated from its default >> implementation, and this is how I was able to swap in >> Jenkins auth as >> the backend. >> >> However, the bad thing about AE is that the assumption >> that AE makes >> about the identity/authentication service is so strict >> that even if I go >> all the way of implementing this contract (with Jenkins >> SecurityRealm as >> the real backend), we won't be able to avoid some >> clunkiness --- for >> example, it has methods like changePassword. >> >> So another conceivable approach is to do federation --- >> we have >> administrators define uses and groups in AE as it is >> today, then we let >> Jenkins users to be linked with AE users, so that once >> you login to >> Jenkins, you automatically login as the corresponding >> linked user in AE. >> >> >> Also, now that I've done it, I think it might make more >> sense for the >> embedded AE to be in a separate plugin from Jenkow. Or >> maybe not, given >> that presumably it doesn't prevent other AE instances to >> run elsewhere >> that connects to the same database. >> >> >> >> This act of embedding a real web application inside >> another web >> application was an interesting work that I really had fun >> with. >> >> Your thoughts would be appreciated. >> >> >> >> [1] https://wiki.jenkins-ci.org/__** >> display/JENKINS/Database+__**Plugin<https://wiki.jenkins-ci.org/__display/JENKINS/Database+__Plugin>< >> https://wiki.jenkins-ci.org/**display/JENKINS/Database+**Plugin<https://wiki.jenkins-ci.org/display/JENKINS/Database+Plugin> >> > >> [2] >> https://github.com/jenkinsci/_**_database-plugin<https://github.com/jenkinsci/__database-plugin>< >> https://github.com/jenkinsci/**database-plugin<https://github.com/jenkinsci/database-plugin> >> > >> >> >> >> >> >> >> >> >> >> -- >> Kohsuke Kawaguchi >> > > -- Kohsuke Kawaguchi
