Problem login to flowable-task because wrong redirect

Flowable Application
#1

Hi,

We have configured a Tomcat with the deployed war for each flowable module, idm, task, modeler, admin and rest.
Login to flowable-idm works without problems, but for the rest of flowable apps we get a wrong redirect to 127:0.0.1:8080. This is the URL format:

http://somedomain.com/flowable-idm/#/login?redirectOnAuthSuccess=true&redirectUrl=http:%2F%2F127.0.0.1:8080%2Fflowable-task%2F

The shared flowable properties “/usr/share/tomcat/lib/flowable-ui-app.properties” is set like this:

idm.app.url=http://somedomain.com/flowable-idm

It seems like it is using/resolving the redirectUrl from elsewhere.

Thanks a lot,

Toni

#2

Hi Toni,

are you running with a proxy in front of the Flowable apps?
The redirectUrl part is fetched from the request.
It makes sense to make the redirectUrl configurable. I’ll create an issue for that so it will be implemented.

Regards,

Yvo

#3

Hi Yvo,

You are right. We are going through a Nginx proxy to bypass 80 port to 8080.
It will be great for the future redirectUrl configuration’s option.
I guess until it gets implemented we have to find another solution, maybe moving tomcat directly to 80 port, or deploy flowable-ui apps directly to Nginx and keeping Tomcat for WebServices calls.

Thanks.
Bests,

#4

Hi Toni,

I had the same issue with Apache httpd webserver. I could solve it by using the AJP protocol when proxying to tomcat instead of HTTP.This correctly preserved the URL from Apache and gave the correct redirect link.

i.e. in apache conf:

ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009/

Not sure if this solution applies to Nginx, but maybe a similar solution exists.

/Paul

1 Like
#5

Hi Toni,

Have you configured the proxyName and proxyPort attributes on the <Connector/> element in your Tomcat server.xml?

You need to set these in order to make the Servlet API calls ServletRequest.getServerName() and ServletRequest.getServerPort() return the proper values in a proxied setup. Additionally, in the common situation where your reverse proxy terminates the https connection[1] and forwards to Tomcat over http, you need to set the scheme and secure attributes as well.

For instance, if your reverse proxy is at https://public.name and your Tomcat at http://172.27.2.2:10080, define the Connector like this:

<Connector address="172.27.2.2" port="10080" protocol="HTTP/1.1" 
    secure="true" scheme="https" proxyName="public.name" proxyPort="443" />

When using the AJP connector rather than the HTTP connector, as @pstapleton did, these attributes may not be needed. The reverse proxy could communicate their values to Tomcat over AJP.

Refer to the Tomcat documentation about Proxying, the HTTP/1.1 Connector and the AJP Connector.

Note: the above assumes that the web application follows the recommendation to use the Servlet API to compose its “public self-URL”, which not all web applications do.

Cheers,
Marco

[1] There is no point in running the flowable-idm over http. You might then as well run without any authentication.

1 Like
#6

Hi Paul,

You are right ! You give me the solution and saved my time. Thanks a lot !!
I have applied a similar solution to Nginx and it solves the issues.
The configuration it is slightly different, I include a proxy_params to the vhost file:

vhosts.conf

server {
. . .
location / {
include proxy_params;
proxy_pass http://tomcat/;
}
. . .
}

proxy_params:

proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

#7

Hi Marco,

Very interesting your explanation on how to use server.xml !

As I have just posted I have found the nginx configuration to make this work, but in other case your solution perfect to solve regardless nginx or apache configuration.
The only drawback I see it is to have the public.name hardcoded in the server.xml.

Tranks a lot,

Toni

#8

The public name isn’t needed in most cases. When Tomcat is configured with virtual hosts (just like Apache and Nginx) it must honour the “Hostname” header in the request, and will set the Servlet.getHostName() accordingly. (Provided that that virtual host is defined.) I’m not sure, but I seem to remember reading that current Tomcats do the same in the default (non-virtual host) setup.

The times I’ve seen Tomcat return redirects to “127.0.0.1” may have also had to do with http/https switching.

#9

I think is a Nginx’s configuration issue, that makes the hostname is not kept in the header. This way Tomcat has not receiving the original hosname.
Having solved this Nginx param the problem was gone without anything to do on Tomcat side.

Toni