Environment: WebSphere App Server / WebSphere Portal 7, fronted by IBM IHS/Apache httpd using was_ap20_module / mod_was_ap20_http.
I have a servlet or JSP page with a redirect like
response.sendRedirect("/wps/myportal/....")
The generated HTTP ends up with the right host and port for the IHS/Apache endpoint but the wrong protocol. It is http instead of https.
For example, if IHS/Apache is listening on https://myserver.com and WAS is on http://192.168.12.34:12345 (all ports/hosts fake), then my redirect comes back as http://myserver.com - correct host and port but wrong protocol.
How does WebSphere figure out the right host/port to use but not the protocol? How can I force the desired behavior?
Add Apache mod_headers to add a custom header before the request is forwarded to websphere, in websphere, set the httpsIndicatorHeader to that custom header, then websphere will know to switch to https
http://www.ibmconnections.org/wordpress/index.php/tag/was-ssl-http-https/
http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.express.doc%2Finfo%2Fexp%2Fae%2Frweb_custom_props.html
Related
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https (http requests are redirected to https requests), the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.
When a user hits a protected page the wildfly presents them with a login page. User enters credentials and submits the login form. The wildfly logs user in and then sends a redirect to the user to send them to the desired page. The redirect sent by the wildfly is an HTTP redirect. This gets grabbed by the load-balancer and redirected to HTTPS but I really want to avoid that second redirect. How can I tell the wildfly to return HTTPS redirect after login instead of HTTP?
I followed link but not sure how to deal same between wildlfy undertow load-balancer and wildfly server.
I followed this link also but didn't get any luck.
Below is the detailed solution explanation for the above problem:
We have a load-balancer sitting in front of two wildfly servers. The load-balancer handles the SSL handshake and forces all traffic over https , the wildfly nodes do not have certificates on them and traffic between load balancer and servers is unencrypted, the wildfly nodes know nothing about the SSL.The communication between load balancer and wildfly nodes is via http protocol.
When a user hits a protected page e.g. https://someip/app
Request flow is as below:
Client browser to load balancer via https
Load balancer to wildlfy nodes via http protocol .
It worked after adding proxy-address-forwarding="true" in wildlfy server node's http
listener .
Our application runs in a JBoss EAP 6.4. Our development setup provides JBoss instance running in HTTP mode on port 8080 and a reverse proxy with both HTTP (port 9090) and HTTPS (port 9443) endpoints to help test different scenarios.
A problem arises when I try to use "current" URL by injecting the UriInfo into my request handlers. The scheme part of the URI inside is always dependent on the scheme attribute of the connector setting in the standalone.xml and not on the actual used scheme. So for example, if I call https://localhost:9443 and http://localhost:9090 when connector's scheme is set to https, both URLs are converted to HTTPS, i.e. https://localhost:9443 but also https://localhost:9090. If I switch connector's scheme to http, both URLs change to HTTP. Needless to say, X-Forwarded-Proto is also ignored.
Is there a way to make JBoss behave more like most other application servers, i.e. without making any assumptions about used environment and especially reverse proxies and load balancers?
RemoteIpValve should do everything you need.
Source code from the JBossWeb 7.5.20 (EAP 6.4.20):
http://anonsvn.jboss.org/repos/jbossweb/tags/JBOSSWEB_7_5_20_FINAL/src/main/java/org/apache/catalina/valves/RemoteIpValve.java
Here's more readable documentation at the upstream Apache Tomcat 7.0 project website:
https://tomcat.apache.org/tomcat-7.0-doc/api/org/apache/catalina/valves/RemoteIpValve.html
The minimum config in your case would be the following global valve configuration in the web subsystem:
<valve name="remoteip-valve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteIpValve">
<param param-name="protocolHeader" param-value="X-Forwarded-Proto"/>
</valve>
This would set the scheme based on the value of the X-Forwarded-Proto header.
For https it would also set the secure flag to true and port to 443.
Since you seem to require the HTTPS port to be set to 9443, you can do it via additional httpsServerPort parameter (and I think you'll also need to set the httpServerPort to 9090 as you mention above, because the RemoteIpValve would override it to 80 otherwise), e.g.
<valve name="remoteip-valve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteIpValve">
<param param-name="protocolHeader" param-value="X-Forwarded-Proto"/>
<param param-name="httpServerPort" param-value="9090"/>
<param param-name="httpsServerPort" param-value="9443"/>
</valve>
And you can do more with that valve if you need, just check the documentation for more details.
It's also briefly described for example here (RH login required): https://access.redhat.com/solutions/629863
BTW If you'd be able to use the AJP protocol (from the proxy to the app. server) instead, this wouldn't be needed as AJP is designed for these cases and all the required information should be transferred to the app. server pretty much transparently.
I use WildFly behind an AWS load balancer. I want the Undertow server in WildFly to redirect http traffic to https, and I can do this mostly successfully with the following line placed in undertow-handlers.conf:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://app.server.com%U)
Thanks to these folks for getting me this far! Now here's my desired tweak. Sometimes I run my web application behind a testing load balancer using 'dev.server.com' and sometimes I run it behind a production load balancer using 'app.server.com.' Currently, I have to remember to manually edit undertow-handlers.conf any time I switch balancers. I'm hoping there is a way to change the hard-coded 'dev' and 'app' to something mechanical. Is there a way to tell Undertow to just use the domain name that was originally requested?
Thanks.
Thankfully the undertow configuration gives you access to the request headers via Exchange Attributes, which you're already using to access the X-Forwarded-Proto header. So the solution is to simply use the Host header from the request like so:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://%{i,Host}%U)
If you want to keep it as part of the deployment try using the %h in the redirect expressions. For example:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://%h%U)
Another option would be to configure the server to handle the redirect for you. The CLI commands would look something like the following assuming the default ports of 8080 for http and 8443 for https.
/subsystem=undertow/configuration=filter/rewrite=http-to-https:add(redirect=true, target="https://%h:8443%U")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=http-to-https:add(predicate="equals(%p, 8080)")
You can see all the possible exchange attributes in the Undertow documentation.
I've got my application on facebook. Its working on https. Recently I've set up the apache reverse proxy. Proxy is doing redirect from https to http port 8080 of tomcat. The game is working if accessed directly. While if accessed from facebook there is an error:
Mixed Content: The page at
'https://apps.facebook.com/pennantrace/?fb_source=bookmark&ref=bookmarks&count=0&fb_bmpos=_0'
was loaded over HTTPS, but requested an insecure form action
'http://thepennantrace.com/'. This request has been blocked; the
content must be served over HTTPS.
UPDATE 1:
I've set spring social facebook's canvas controller's post login url to the "https://..." now it works but tomcat is redirecting the call to https://...com to the http://....com/resources/index.html
Seems like all redirects from tomcat are passed as they are (http) without changing the protocol to the https.
I fixed it by setting apache to use X-Forwarded-Proto
And tomcat to respond on that correctly.
I have a web application running on Weblogic. The HTTPS URL to this application is https://localhost:7002/MyApp.
Whenever I am changing the URL in the address bar to http://localhost:7002/MyApp, it automatically redirects to the original HTTPS based URL.
My requirement is to take the user to some kind of custom error page, if they request the HTTP URL. For example, http://localhost:7002/MyApp should redirect to https://localhost:7002/MyApp/error.jsp.
Is this redirection possible to configure in Weblogic?
You mentioned that your https URL is:
https://localhost:7002/MyApp
And assuming that your http URL is:
http://localhost:7001/MyApp
When you say you change the https URL in browser to:
http://localhost:7002/MyApp
This is in-correct. If you provide such a URL, WLS will accept the request on secure port 7002 but will fail to identify the protocol (it expected https but you gave http). Instead of a redirection, you would get some error in browser and definitely following error in WLS logs:
<May XX, 2013 XX:XX:17 PM IST> <Warning> <Security> <BEA-090475> <Plaintext data for protocol HTTP was received from peer
XXXXXXXXXXXXXX - 192.169.0.100 instead of an SSL handshake.>
I assume you are changing the URL to:
http://localhost:7001/MyApp
Please correct/update your issue description.
Now onto your requirement, it seems nearly impossible to do this via WLS configuration.
As a workaround, you can create a servlet filter and call isSecure on ServletRequest to determine whether the request was made using secure protocol or not. If you find it was not, then you can redirect to some custom page. And you would also need to disable this automatic redirection to https that you have reported for your application.
Ref: http://docs.oracle.com/javaee/6/api/javax/servlet/ServletRequest.html#isSecure%28%29