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
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/ 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
[2] https://github.com/jenkinsci/database-plugin
