We Keep Coding

Hateoas links generated with internal hostname instead of forwarded host after upgrade

We recently upgraded to Spring 5.1.3 and Hateoas 0.25 and started facing problems with the generated links.
Say our domain is xyz.com and all requests that come to any subsystem via the load-balancer are forwarded to the main system where the hateoas links generated had links with xyz.com domain.
However, after the upgrade, the hateoas links generated for such requests now have the internal hostname eg. host5678.internaldomain.com.
I came across an issue logged for this at: https://github.com/spring-projects/spring-hateoas/issues/753 where it provided an interim solution via https://stackoverflow.com/a/53269319 which recommends using FilterRegistrationBean
It appears that FilterRegistrationBean is available as part of Spring Boot which we don't use so that solution is out of the question.
So I tried adding a new filter ForwardedHeaderFilter directly in the application web.xml. However, this creates problems with redirect URLs with HTTPS getting converted to HTTP.
The other solution mentioned was to upgrade to 0.25.1 and use Spring property server.use-forward-headers=true. Upgrade is done but I couldn't find XML equivalent of this property as we are using Spring XML for configuration.
Any help with this regards would be sincerely appreciated.

Found the answer after going through the source and trying some different combinations.
The issues mentioned in the question have been fixed in the Hateoas release 0.25.1 so one part of the solution was to upgrade Hateoas to 0.25.1.
The other part is inspired from the SO link given in the question but it didn't work as is, in my case since that is applicable for Spring Boot only. Since we don't use Spring Boot but we have a traditional web application running with a J2EE container, the solution is to include the ForwardedHeaderFilter as part of the web application's web.xml as follows:
<filter>
<filter-name>forwardedHeaderFilter</filter-name>
<filter-class>org.springframework.web.filter.ForwardedHeaderFilter</filter-class>
<init-param>
<param-name>relativeRedirects</param-name>
<param-value>true</param-value>
</init-param>
</filter>
<filter-mapping>
<filter-name>forwardedHeaderFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Caching of Static Files in GWT

Developed application using GWT which contains lot of static files(javascript,css,images) which i want to cache for 30 days. I read lot of blogs but didn't get any clue.
- How to cache static files?
- What are the possible option to achieve caching (do i need to configure in server or GWT application, here i am using glassfish/payara server for deployment)
Any idea?
Note: I want do achieve this with minimal code changes, even i read this Client side caching in GWT
but don't want to go with dispatcher approach

You will need to add something like the ExpiresFilter to your servlet container.
I'm adding the details for the configuration from the link mentioned above just in case the content of the link goes away:
You will need to edit web.xml to add a filter and a filter mapping:
<filter>
<filter-name>ExpiresFilter</filter-name>
<filter-class>server.ExpiresFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ExpiresFilter</filter-name>
<url-pattern>/images/\*</url-pattern> <!-- these patterns should match cached resources -->
<url-pattern>/resources/\*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
If you need a more portable approach for use in different application servers, you might end up writing a generic servlet Filter like I did.
After all that is no big deal as you just have set the Expires and Cache-Control: max-age headers for HttpServletRequests on your given paths.
As a starter, I stumpled upon this implementation and how Tomcat does it.

Shiro in a multi-threaded environment

The basic way that I understand Shiro's SecurityUtils.getSubject() to work is that it returns the subject which is bound to the currently executing thread. However, this just seems at odds with a servlet container like Tomcat which is using a thread pool to service requests.
If Tomcat is say using ThreadA to handle requests, any calls to SecurityUtils.getSubject() should work fine. But, as soon as ThreadB is selected, the user is lost, getSubject returns null and isAuthenticated is now false. This is even though the user is still logged in.
I have confirmed this in my application. I am using Shiro Core 1.2 and notice that my user is just miraculously being inauthenticated when I navigate through my app. If I look at the logs, the problem happens as soon as a different thread is used to service the request.
So, do I have Shiro configured incorrectly? It seems like the 'current user' should be bound to something a bit more longer-lasting than the current thread. I would expect it to be session-based. I know that Shiro has session management, but in all examples I've found, it says to get the current user by calling getSubject, which looks at the ThreadContext. Am I missing something?

So, it turns out that I just didn't have Shiro configured correctly. I have a web app, yet I was setting up the Security Manager in code. This resulted in the Security Manager being set up on a certain thread only. As long as requests were serviced by that same thread, it worked fine. But as soon as Tomcat chose a different thread, the user appeared inauthenticated.
Shiro has a filter for web apps that handles this scenario and binds the user to each incoming request. You should have your app configured as follows instead of doing the security manager in code:
<context-param>
<param-name>shiroConfigLocations</param-name>
<param-value>classpath:auth.ini</param-value>
</context-param>
<!-- Shiro Environment Listener -->
<listener>
<listener-class>org.apache.shiro.web.env.EnvironmentLoaderListener</listener-class>
</listener>
<!-- Shiro Filter Configuration -->
<filter>
<filter-name>ShiroFilter</filter-name>
<filter-class>org.apache.shiro.web.servlet.ShiroFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>ShiroFilter</filter-name>
<url-pattern>/*</url-pattern>
</filter-mapping>

Servlet filter url mapping

How can a filter be mapped to the root of a URL? I'm using Tomcat 7.0.2 and deploying an application as ROOT.war. The welcome page is sign_in.xhtml. I would like to run a filter whenever the client sends a request for the root of the site (i.e. the domain name only), or when the the client requests sign_in.xhtml. Here is what I have so far:
<filter>
<filter-name>My filter</filter-name>
<filter-class>com.myApp.myFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>My filter</filter-name>
<url-pattern>/sign_in.xhtml</url-pattern>
</filter-mapping>
Requests for sign_in.xhtml directly, successfully invoke the filter, but I'm not sure how to get requests for the root to invoke the filter. According to the Servlet spec (version 3.0)
<url-pattern>/</url-pattern>
maps to the default servlet, and an empty string maps to the root. Here's the relevant section from the spec:
"The empty string ("") is a special URL pattern that exactly maps to the
application's context root, i.e., requests of the form http://host:port//. In this case the path info is ’/’ and the servlet path and context path is
empty string (““)."
However, both of the following url patterns cause Tomcat to throw an exception.
<url-pattern></url-pattern>
<url-pattern>""</url-pattern>
I would really appreciate it if someone could shed some light on this. Thank You.
Andrew

The <url-pattern>/</url-pattern> should work for requests on the root. Did you try it?
If your intent is more to filter all requests, then you should use <url-pattern>/*</url-pattern>.
Update: To exclude one and other, I tested the url-pattern of / at Tomcat 7 (using both web.xml and #WebFilter(urlPatterns={"/"})) and it indeed didn't work as expected. The url-pattern of / however works as expected on Tomcat 6 (Servlet 2.5) and also on Glassfish v3 (Servlet 3.0). I suspect a bug in Tomcat 7, so I've reported issue 49914 about this.

Configure Tomcat to send web pages compatible to IE 7 or 6

I have got an application that is not compatible to work using IE8 browser.
I am looking for a way to to configure Tomcat on which this application run, so the pages could be read by IE8 and treated as if they are IE7 or IE6
By googling so far I found a possible suggestion which say to add to the http response the header:
X-UA-Compatible: IE=EmulateIE7
here
that tell IE8 to be like IE7.
The problem is that this way requires adding a filter that should be added on application level. I'd like to know if any of you is familiar with a more generic way that Tomcat enables to send its http content to be IE7 (or IE6) compatible ?

Download urlrewritefilter-4.0.3.jar from http://tuckey.org/urlrewrite/
Add urlrewritefilter-4.0.3.jar to WEB-INF/lib
Add following code to WEB-INF/web.xml
<filter>
<filter-name>UrlRewriteFilter</filter-name>
<filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
<filter-name>UrlRewriteFilter</filter-name>
<url-pattern>/*</url-pattern>
<dispatcher>REQUEST</dispatcher>
<dispatcher>FORWARD</dispatcher>
</filter-mapping>
Make a new configuration file for the module. (WEB-INF/urlrewrite.xml)
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE urlrewrite PUBLIC "-//tuckey.org//DTD UrlRewrite 4.0//EN" "http://www.tuckey.org/res/dtds/urlrewrite4.0.dtd">
<urlrewrite>
<rule><condition name="user-agent">.*MSIE.*</condition>
<set type="response-header" name="X-UA-Compatible">IE=EmulateIE7</set>
</rule>
</urlrewrite>

Tomcat is a general purpose webserver and servlet container. It is absolutely browser-agnostic thus, there's no way to configure it in some special way to deal with IEs.
You don't have to add filter really. The bare minimum is to set the response header anywhere in "service" method (or doGet or doPost, whatever application uses):
res.addHeader("X-UA-Compatible", "IE=EmulateIE7 ");
But this is in case when there's a single entry point in the server application. Otherwise filter should do the job in a better way.

See this forum thread that discusses exactly the same situation you are describing. It seems that a filter is the best way to go. As an answer at the above thread suggests, you could use Url Rewrite Filter.
Also, if you are using Apache Web Server to proxy Tomcat, you could easily configure it to add any header to the response.