10:56 p.m.
[
https://issues.jboss.org/browse/WFLY-9496?page=com.atlassian.jira.plugin....
]
I J commented on WFLY-9496:
---------------------------
I see what you are getting at. The problem is externally browsers only ever point to
80/443 unless your links are exlicity employing nonstandard ports. No user...
I have domains that need to be seen and managed via a single public address. One that
uses the standard external address: port 80. Routers, possessing a single public
interface, understandably, can only map that port to a single internally homed machine.
Ie. external port 80 must map to internal ip:port something. Given this if a browser
chooses a non-ssl protocol and I want to force a redirect to an ssl protocol, I can't
without affect all apps served from that server. Which would be fine if all my apps are
externally exposed. Apps that are in development and may not currently have a domain name
and dns record break the model because there is no external reference in the dns. When I
set up a reference in the internal hosts file to access these dev stage apps wildfly https
redirects force them to be external and since there is no dns for that placeholder name
the mechanism fails.
Unfortunately I can't simply reference the hostname as referenced in the local hosts
file appended with the https listener port binding, ie. Host1:8443, as that binding forces
the browser to insert the https address line reference, again, an external reference.
This all being said, you have solved my problem admirably as I know a little more
regarding Wildfly's operating methododolgy, I am able to move forward.
My solution was to remove the forced redirect reference in the web.xml file for apps under
development. Not ideal as some of the app code tests the protocol before completing the
task in question (ie. App login functionality that tests whether or not the protocol
being employed is secure via tls among others...).
What I have done is created an unreferenced alias to one of my external apps and am
testing the functionality as a component of that app. Once I am sure of the domain name
and make the purchase I will secure the development app with some form of secure-auth
integrating the modules that test for the secure condition before going live.
I went this route as, while kludgy, I am not sure if exploring the domain configuration
will resolve this issue? (I don't believe is will - the problem I am facing is a https
issue by design and that it is me that must change my methodology).
Thanks again Stuart! I have my path... :)
WildFly 10.1 Final: Virtual Hosting
------------------------------------
Key: WFLY-9496
URL: https://issues.jboss.org/browse/WFLY-9496
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.1.0.Final
Environment: Linux debian 4.9.0-3-amd64 #1 SMP Debian 4.9.30-2+deb9u5
(2017-09-19) x86_64 GNU/Linux
JAVA_HOME: null
java.version: 1.8.0_151
java.vm.vendor: Oracle Corporation
java.vm.version: 25.151-b12
os.name: Linux
os.version: 4.9.0-3-amd64
WildFly: 10.1.0.Final
Reporter: I J
Assignee: Stuart Douglas
Priority: Critical
Labels: new_and_noteworthy
Attachments: Screenshot from 2017-10-30 19-25-12.png, wireshareNative.gz.pcap,
wireshark
My configuration:
========= standalone-full.xml ===============
<subsystem xmlns="urn:jboss:domain:undertow:3.1">
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http"
redirect-socket="https" enable-http2="true"/>
<https-listener name="https" socket-binding="https"
security-realm="ApplicationRealm" enable-http2="true"/>
<host name="default-host" alias="localhost">
<location name="/" handler="welcome-content"/>
<filter-ref name="server-header"/>
<filter-ref name="x-powered-by-header"/>
</host>
<host name="host1" alias="domain1.com,www.domain1.com"
default-web-module="domain1-war.war"/>
<host name="host2" alias="domain2.com,www.domain2.com"
default-web-module="domain2-war.war"/>
</server>
<servlet-container name="default">
<jsp-config/>
<websockets/>
</servlet-container>
<handlers>
<file name="welcome-content"
path="${jboss.home.dir}/www/welcome-content"/>
</handlers>
<filters>
<response-header name="server-header"
header-name="Server" header-value="WildFly/10"/>
<response-header name="x-powered-by-header"
header-name="X-Powered-By" header-value="Undertow/1"/>
</filters>
</subsystem>
============ /etc/hosts ============
127.0.0.1 localhost host1 host2
=========== domain1-war/WEB-INF/jboss-web.xml =========
<jboss-web>
<virtual-host>host1</virtual-host>
<context-root>/</context-root>
</jboss-web>
=========== domain2-war/WEB-INF/jboss-web.xml =========
<jboss-web>
<virtual-host>host2</virtual-host>
<context-root>/</context-root>
</jboss-web>
[EDIT] ============================================
Wildfly is launched as per: [opt/wildfly/bin] ./standalone.sh -b=0.0.0.0
-c=standalone-full.xml
Thus socket bindings should not be an issue.
Notes:
1. Server starts and all deploys and works as expected when access as host1:8080,
host2:8080, localhost:8080
Thus my webapps along with the wildfly default ROOT.war (welcome pages) work as
expected.
2. Router port 80 is forwarded to 8080
3. When using the server aliases as defined in standalone-full.xml, in my case
domain1.com or domain2.com the server times out and I get nothing.
4. I have intercepted the request headers for domain1.com and domain2.com and they are
correct.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
2937
days inactive
2937
days old
0 comments
1 participants
participants (1)
-
I J (JIRA)