Wildfly redirects from HTTPS back to HTTP

[rsoika]

Hi,

I have a strange behavior with HTTPS and Wildfly 9.0.2.

My JSF application runs on localhost on port 8080 on Wildfly. In front of the wildfly server there is  a reverse proxy (Squid) which maps the application to a domain which can be accessed via HTTP and HTTPS. On the first view everything works fine and the application works on HTTPS when accessed form the mapped domain. But always when the application triggers a JSF navigation rule with the '<redirect />' tag, Wildfly redirects from HTTPS back to HTTP.

This is a HTTP log from such a situation illustrating the behavior:

   20 ----------------------------------------------------------
   21 https://demo.office-workflow.de/office
   22
   23 GET /office HTTP/1.1
   24 Host: demo.office-workflow.de
   25 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:40.0) Gecko/20100101 Firefox/40.0
   26 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
   27 Accept-Language: en-US,en;q=0.5
   28 Accept-Encoding: gzip, deflate
   29 Cookie: JSESSIONID=HaY0fNYyCgDY3mG1RkMQTYfQGW-napPQ89sNCagZ.vm02
   30 Connection: keep-alive
   31
   32 HTTP/1.0 302 Moved Temporarily
   33 X-Powered-By: Undertow/1
   34 Server: WildFly/9
   35 Location: http://demo.office-workflow.de/office/
   36 Content-Length: 0
   37 Date: Mon, 23 Nov 2015 13:15:36 GMT
   38 X-Cache: MISS from localhost
   39 X-Cache-Lookup: MISS from localhost:80
   40 Via: 1.0 localhost (squid/3.1.20)
   41 Connection: keep-alive
   42 ----------------------------------------------------------
   43 http://demo.office-workflow.de/office/

As you can see in line 32 the wildfly http server redirects form HTTPS to HTTP

I tried various attempts to solve this problem with WebFilter and Custom NavigationHandlers but with no success.

Can anybody explain why Undertow redirects with changing the protocol type? Is there a workaround to avoid this behavior?

Thanks for help

Ralph

[swd847]

Wildfly is not aware of the proxy. You need to add:

proxy-address-forwarding="true"

to the HTTP listener and make sure the proxy is sending an

X-Forwarded-Proto: https

header.

[rsoika]

Hm - the problem seems to be squid which we are using as our reverse proxy. There seems to be no configuration to set the request header 'X-Forwarded-Proto: https'.

I did activate the undertow request dump to see what happens. Below you can see the log form the situation where the JSF application makes a redirect (302) to another page (this is where a navigation rule uses the '<redirect />' configuration). From that point all future requests come with HTTP instead of HTTPS

2016-01-06 12:39:04,842 INFO  [io.undertow.request.dump] (default task-13) 
----------------------------REQUEST---------------------------
               URI=/office/pages/workitems/workitem.jsf
 characterEncoding=null
     contentLength=205
       contentType=[application/x-www-form-urlencoded]
            cookie=JSESSIONID=xpy9PKw7lRCrjaSTtFW7Jc9fpZAAZqNWydNRdeJW.vm02
            cookie=imixs.office.navigation=/pages/notes.jsf
            cookie=imixs.workflow.locale=de_DE
            header=Accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
            header=Accept-Language=de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
            header=Cache-Control=max-age=0
            header=Accept-Encoding=gzip, deflate
            header=Origin=https://demo.office-workflow.de
            header=User-Agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36
            header=Surrogate-Capability=unset-id="Surrogate/1.0 ESI/1.0"
            header=Via=1.1 localhost (squid/3.1.20)
            header=Connection=keep-alive
            header=X-Forwarded-For=80.137.115.62
            header=Content-Length=205
            header=Content-Type=application/x-www-form-urlencoded
            header=Cookie=JSESSIONID=xpy9PKw7lRCrjaSTtFW7Jc9fpZAAZqNWydNRdeJW.vm02; imixs.workflow.locale=de_DE; imixs.office.navigation=/pages/notes.jsf
            header=Referer=https://demo.office-workflow.de/office/pages/workitems/workitem.jsf?id=151b8e7fefd-11a306af
            header=Upgrade-Insecure-Requests=1
            header=Host=demo.office-workflow.de
            locale=[de_DE, de, en_US, en]
            method=POST
          protocol=HTTP/1.1
       queryString=
        remoteAddr=80.137.115.62:0
        remoteHost=80.137.115.62
            scheme=http
              host=demo.office-workflow.de
        serverPort=8081
--------------------------RESPONSE--------------------------
     contentLength=0
       contentType=null
            header=Expires=0
            header=Cache-Control=no-cache, no-store, must-revalidate
            header=X-Powered-By=Undertow/1
            header=Server=WildFly/9
            header=Pragma=no-cache
            header=Location=http://demo.office-workflow.de/office/pages/home.jsf
            header=Date=Wed, 06 Jan 2016 11:39:04 GMT
            header=Connection=keep-alive
            header=Content-Length=0
            status=302
==============================================================
2016-01-06 12:39:05,064 INFO  [io.undertow.request.dump] (default task-12) 
----------------------------REQUEST---------------------------
               URI=/office/pages/home.jsf
 characterEncoding=null
     contentLength=-1
       contentType=null
            cookie=JSESSIONID=xpy9PKw7lRCrjaSTtFW7Jc9fpZAAZqNWydNRdeJW.vm02
            cookie=imixs.office.navigation=/pages/notes.jsf
            cookie=imixs.workflow.locale=de_DE
            header=Accept=text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
            header=Accept-Language=de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
            header=Cache-Control=max-age=0
            header=Accept-Encoding=gzip, deflate, sdch
            header=User-Agent=Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.80 Safari/537.36
            header=Surrogate-Capability=unset-id="Surrogate/1.0 ESI/1.0"
            header=Connection=keep-alive
            header=Via=1.1 localhost (squid/3.1.20)
            header=X-Forwarded-For=80.137.115.62
            header=Cookie=JSESSIONID=xpy9PKw7lRCrjaSTtFW7Jc9fpZAAZqNWydNRdeJW.vm02; imixs.workflow.locale=de_DE; imixs.office.navigation=/pages/notes.jsf
            header=Upgrade-Insecure-Requests=1
            header=Host=demo.office-workflow.de
            locale=[de_DE, de, en_US, en]
            method=GET
          protocol=HTTP/1.1
       queryString=
        remoteAddr=80.137.115.62:0
        remoteHost=80.137.115.62
            scheme=http
              host=demo.office-workflow.de
        serverPort=8081
--------------------------RESPONSE--------------------------
     contentLength=1451
       contentType=text/html;charset=UTF-8
            header=Expires=0
            header=Cache-Control=no-cache, no-store, must-revalidate
            header=X-Powered-By=Undertow/1
            header=Server=WildFly/9
            header=Pragma=no-cache
            header=Date=Wed, 06 Jan 2016 11:39:05 GMT
            header=Connection=keep-alive
            header=Content-Type=text/html;charset=UTF-8
            header=Content-Length=1451
            status=200

[ctomc]

Squid *does* have this option.

see http://www.squid-cache.org/Versions/v3/3.3/cfgman/request_header_add.html

all you need to do is to add config option:

request_header_add X-Forwarded-Proto https

another option is to use WildFly 10 that added option "secure=true|false" for http-listener which tells the server that all requests that come in are "secure" even when they come over http. this is useful for scenarios like this.

[rsoika]

Hi, yes I have also seen this and we will test the parameter so I can hopefully give a positive feedback soon.

Thanks for your help!

[rsoika]

After updating Squid to latest release we where able to set the request_header "X-Forwarded-Proto: https" . Now everything works fine. Thanks again for help.