Is there a way to disable compression of keycloak server output. I try to rewrite the HTML content so that I can proxy pass the Keycloak front end with my Apache http.
Currently I try ProxyPassReverse, mod_rewrite and mod_substitude but nothing works. IMO the reason is the wildfly server delivere the content gziped.
Any ideas?
I think you can disable this on undertow subsystem in your standalone.xml or standalone-ha.xml (depends on profile you use), by default the undertow has no gzip filtering, but you should see something like this in your config.
```
<gzip name="gzipFilter"/>
```
Related
Quick and dirty fix needed here if possible...
We've been running a bunch of REST services on a Wildfly installation for a few years. The server isn't for public use -- on the main https://ourserver.com page we have a redirect which points wandering users to our main website. It's a very simple standalone config.
But the server has always been HTTPS only. And now thanks to a domain reshuffle, we need to make it possible for users who go to http://ourserver.com without SSL to hit the redirect to ourserver.net. So we basically need to expose just the welcome-content directory on this server over the "http" interface (which was previously firewalled off), while not letting non-SSL users reach any of the webservice subdirectories.
What's the simplest way to ensure that accessing any URL via plain HTTP gets redirected?
You can try adding a filter to the standalone.xml under the subsystem urn:jboss:domain:undertow:4.0
e.g. for http (8080) to https (8443), it would be:
<filter-ref name="http-to-https" predicate="equals(%p,8080)"/>
under the tag filters, you add it:
<rewrite name="http-to-https" target="https://myhttpsurl.com:8443%U" redirect="true"/>
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.
Is it possible to expose JMX interface over RMI, not over http-remoting? Or expose via both?
It would be great to access Mbeans via url like "service:jmx:rmi//" to be able to establish zabbix gate monitoring. Zabbix has an issue with hard-coded value in connection url ([ZBXNEXT-1274] Configurable JMX Endpoint - ZABBIX SUPPORT)
As far as I understand I need to add additional connector to jmx subsystem. Is is correct?
Part of xml for jmx subsystem is default for now and looks like this:
<subsystem xmlns="urn:jboss:domain:jmx:1.3">
<expose-resolved-model/>
<expose-expression-model/>
<remoting-connector/>
</subsystem>
Thanks!
I'm not sure that it is possibly to add alternative JMX access protocols in WildFly. At least not as a supported configuration option.
It might be possible to expose JMX via the standard JVM parameters, as described in the Java Documentation, but I would not expect it to be working correctly.
An alternative solution for enabling monitoring from Zabbix is to expose some or all of the JMX MBeans through a http or RESTful interface with Jolokia or other similar technology.
zabbix in version 3.4 have Configurable JMX Endpoint.
https://www.zabbix.com/documentation/3.4/manual/config/items/itemtypes/jmx_monitoring
You need only upgrade zabbix, add jar for application server in zabbix and change endpoint in template. I have success setting with wildlfy 10,10.1 and 11. Both modes is supported (domain and standalone).
Is it possible that weblogic uses a custom ssl socket implementation? I'm running into a problem with the JavaMail. Trying to use a smtp ssl connection fails even though I've setup a custom truststore with the mailserver ca. However if I set the javax.net.ssl.trustStore property to use a truststore with the mailserver ca everything works.
This makes me think that weblogic uses their custom sockets or custom config for sockets. While JavaMail relies on the standard mechanisms and will not take into account what's in the weblogic custom truststore.
Any ideas?
(posted as an answer - thanks!)
WebLogic Server doesn't use custom socket implementation that I'm aware of. I've integrated it in the past with a number of client applications or other servers. That being said, SSL is gloriously frustrating to get working right. Can you post the exceptions/errors you're getting in your logs when WebLogic Server tries to make the connection? If you're not seeing anything in the logs, depending on the version of WebLogic Server you're using, there are a number of debug flags you can enable to get more information.
By default WebLogic uses the Certicom SSL implementation. My experience of this library has been nothing but grief. You haven't provided any details of the error but I would enable the Sun implementation to see if that helps. In the "Advanced" tab in the SSL-configuration there is a checkbox called "Use JSSE SSL" which will do it.
Or you can do it with system properties like so:
http://weblogic-wonders.com/weblogic/2010/11/09/enforce-weblogic-to-use-sun-ssl-implementation-rather-than-certicom/