console file upload

[tom.baeyens]

the graphical designer can't seem to do a file upload

David, could you have a look at this ?

java.io.FileNotFoundException: http://localhost:8080/jbpm-console/upload
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1172)
at org.jbpm.ui.util.ProcessDeployer.deployProcessWithServlet(Unknown Source)
at org.jbpm.ui.util.ProcessDeployer.access$3(Unknown Source)
at org.jbpm.ui.util.ProcessDeployer$1.run(Unknown Source)
at org.eclipse.jface.operation.ModalContext.runInCurrentThread(ModalContext.java:369)
at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:313)
at org.eclipse.jface.dialogs.ProgressMonitorDialog.run(ProgressMonitorDialog.java:479)
at org.jbpm.ui.util.ProcessDeployer.showProgressMonitorDialog(Unknown Source)
at org.jbpm.ui.util.ProcessDeployer.deploy(Unknown Source)
at org.jbpm.ui.editor.form.deployment.DeploymentForm$1.widgetSelected(Unknown Source)
at org.eclipse.swt.widgets.TypedListener.handleEvent(TypedListener.java:90)
at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:66)
at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:928)
at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:3348)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:2968)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:1914)
at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:1878)
at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:419)
at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149)
at org.eclipse.ui.internal.ide.IDEApplication.run(IDEApplication.java:95)
at org.eclipse.core.internal.runtime.PlatformActivator$1.run(PlatformActivator.java:78)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:92)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:68)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:400)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.eclipse.core.launcher.Main.invokeFramework(Main.java:336)
at org.eclipse.core.launcher.Main.basicRun(Main.java:280)
at org.eclipse.core.launcher.Main.run(Main.java:977)
at org.eclipse.core.launcher.Main.main(Main.java:952)

[dmlloyd]

This function does not exist in the current console. One of the key requirements is that the console is usable out of the box for administration of a jBPM installation. The GPD relies on unauthenticated access to upload processes. Therefore we should have a separate WAR file that contains this servlet (and any other development-time no-security servlets) that can be deployed during development and removed in a production environment. Otherwise we have a pretty scary security hole.

Ideas?

[estaub]

David,

Does this mean there's now no way to deploy, or am I missing something?

While I think a separate WAR may well be a good thing, I don't think it's generally practical to rely on removing it to provide security in a "production environment".

Even after being in production, folks will need to deploy new versions of existing processes, presumably pre-tested on a non-production server.

A server may be "in production" relative to one process definition, but be "in development" relative to another.

-Ed Staub

[dmlloyd]

You can deploy a process archive from within the console currently. But right now there is no way to deploy from the GPD. This is obviously not going to be a permanent situation.

Obviously jBPM would not be useful without the ability to deploy a process. :-)

[tom.baeyens]

to get started, i think we need to add the upload servlet again without security.

but the point is valid and it needs to be fixed. but i only want to do that in 3.2.2 at the earliest

one of the ideas we had was to see if we can add authentication to the file upload.

even in case we get the http based authentication to work, it still results in an equally big security hole. since we want things to work out of the box, the default unzip installation will have to contain a preconfigured designer with the username and password for process deployment. Then the server, will have the same data in the identity component.

a separate web app doesn't seem to be a solution either i think. as it is easier to delete the .war then removing the servlet from the web.xml. BUT... then we have to mess with building the 3 separate wars, both containing the jbpm libs in duplicate. Also we have to mess with the enterprise.ear deployment. Removing the upload servlet from the enterprise ear deployment will be more painfull then just removing the servlet configuration from the web.xml

so we have to find a decent solution in 3.2.2, but in the meantime, i would like to have the upload servlet reintroduced to get the suite working again as i want to work my way to releasing 3.2.1.

[kukeltje]

what about a war file with the upload servlet and basic authentication on it (not formbased) I think that if the url in the gpd is configured in the form of http://:@hostname.domain.tld/jbpm-concole/upload

it should work

[kukeltje]

ahhhhh sorry, should be

http://<username>:<password>@hostname.domain.tld/jbpm-console/upload

[camunda]

a little bit off topic here maybe, but to give the remark:

It would be cool if the Eclpse plugin could also deploy via the DeployProcessCommand to a SessionBean. The only thing you would need to configure is the jndi.properties and the JNDI name of the ServiceCommand.

But just as a remark, not very urgent...

[estaub]

Ronald,

>> http://:@hostname.domain.tld/jbpm-console/upload

I'm sure some folks would not want to send passwords in the clear.
How hard would https be?

-Ed

[koen.aers]

I was just waiting (already for a year or more) for this issue to come up :-))

As Tom already told, it has to be fixed. The proper sequence of steps is probably to first follow Ronald's suggestion with the possibility to set the credentials somewhere in a preference page. As a followup we could investigate to use https to do the authentication, but to do that, we need to adapt the console.
In any case, we need to ask ourselves if someone would really use the designer to deploy in a production setting.

Cheers,
Koen

[kukeltje]

https would not be difficult for eclipse (using a client certificate would, not basic authentication)

Configuring JBoss (or the web frontend) is. but if people want to do this.... it's up to them. I do not see a problem here.. Besides that, the form based authentication is also http atm....

I was just waiting (already for a year or more) for this issue to come up :-))

WHAT and you did not do anything about it? Not even file a Jira issue... shame on you

In any case, we need to ask ourselves if someone would really use the designer to deploy in a production setting.

Agreed.... we wouldn't

[koen.aers]

WHAT and you did not do anything about it? Not even file a Jira issue... shame on you

Some sleeping dogs should not be alarmed ;-)

Cheers,
Koen

[estaub]

Zzzz ... Zzzz ... Zzzzz

[dmlloyd]

Tom has urged me to put this servlet back in - so for now I'm just going to put a large warning/disclaimer about removing the servlet before putting the application into production.

I hope that everyone reads closely all the configuration files in the console when deploying to production. For this reason, one of the packaging options for the console is an exploded war, where all the configuration files are easily accessed.

[tom.baeyens]

Tom has urged me to put this servlet back in - so for now I'm just going to put a large warning/disclaimer about removing the servlet before putting the application into production.

i want to proceed along 2 tracks concurrently.

first i want to restore the previous situation to make sure the gpd deployment works again and so that we can do an update release asap. i don't want to stall the current release because of this issue.

secondly we need to keep thinking in this thread to find the real solution to the problem.