GWT app doesn't work behind reverse proxy

[dhoffer]

We have a GWT app using (2.6.1) that is deployed to Tomcat and has been working fine, recently Tomcat's FORM container authentication was added and that too was working well.  The problem is now we want to put the app/Tomcat behind an Apache reverse proxy so end users get a nice URL and this is breaking the app.  First it breaks Tomcat's FORM authentication, we now get 408 errors when trying to log into the app.  As a test we took out the authentication and found that the client side UI works fine but all calls to the server fail, e.g. all RPC calls fail too.  This later problem seems similar/same as what is described here http://stackoverflow.com/questions/1517290/problem-with-gwt-behind-a-reverse-proxy-either-nginx-or-apache

What is the solution here?  I could try the approach in the link above but that only addresses the GWT part, I need that and authentication.  Putting the app behind a reverse proxy seems such a common thing to do it seems we are missing something here that will fix both issues.

Btw, the problem 'seems' to be that if the proxy is like this: 

ProxyPass /appname http://localhost:8080/appcontext/myapp
ProxyPassReverse /appname http://localhost:8080/appcontext/myapp

What seems to be happening is that the requests that the app gets has 'appname' as the URL instead of the expected '/appcontext/myapp'.

-Dave

[Jens]

The "issue" is that GWT will send you the moduleBaseURL as payload from the client to the server and the server uses that value to find the RPC policy file on disk. When you use a reverse proxy then the moduleBaseURL will not change when passing the proxy, it will always be http://domain.com/appname/<modulename> or http://domain.com/<modulename> (depends on how you deploy your app). Because of this GWT's default implementation of RemoteServiceServlet.doGetSerializationPolicy() does not work anymore as it tries to match the moduleBaseURL with the server context path which can now be totally different because of the proxy.

So you either have to write custom code to find the RPC policy file on your server (thats what I also do at the moment) or you can try overriding the default moduleBaseURL on the client by using <meta name='gwt:property' content='baseUrl=/appcontext/myapp'> in your host page.

Also keep in mind when you use a reverse proxy that you might need to rewrite cookie domains / paths as well. In apache you can do that with ProxyPassReverseCookieDomain and ProxyPassReverseCookiePath.

-- J.

[David Hoffer]

Jens,

Thanks for the reply and information, it sounds like there is a workaround then for the GWT part but we still have the same/similar issue with Tomcat's authentication.  We need to solve that too else its only a partial solution.

Btw, regarding the GWT serialization issue...I read online some say a way around this is to use IsSerializable instead of Serializable to mark objects going across the wire but its not clear if that 'trick' still works or not.  Also some say to drop GWT RPC and use JSON instead that doesn't have the same issue.  I don't really care what the format of the data is going across the wire, I just need the results to work.  Is there an easy way to switch the RPC format to JSON or some other format that doesn't have this issue?

-Dave

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/Zi_dtUEePlY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-tool...@googlegroups.com.
To post to this group, send email to google-we...@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.

[Michael Joyner]

Something else you can do to handle the RPC portion of the issue in the servlet is to do:

@Override
    protected SerializationPolicy doGetSerializationPolicy(
            HttpServletRequest request, String moduleBaseURL, String strongName) {
        moduleBaseURL = request.getScheme() + "://" + request.getServerName()
                + (new File(request.getRequestURI()).getParent() + "/");
        return super.doGetSerializationPolicy(request, moduleBaseURL,
                strongName);
    }

On 07/09/2015 10:16 AM, dhoffer wrote:

[Jens]

Thanks for the reply and information, it sounds like there is a workaround then for the GWT part but we still have the same/similar issue with Tomcat's authentication.  We need to solve that too else its only a partial solution.

I am not familiar with tomcat and your overall setup but it sounds like your session cookie might not be correct during authentication and you reach some login timeout. Maybe Tomcat sets a JSESSIONID cookie for localhost when accessed through the proxy. Thats why I said you might need to rewrite cookies in your proxy.

 

Btw, regarding the GWT serialization issue...I read online some say a way around this is to use IsSerializable instead of Serializable to mark objects going across the wire but its not clear if that 'trick' still works or not.  Also some say to drop GWT RPC and use JSON instead that doesn't have the same issue.  I don't really care what the format of the data is going across the wire, I just need the results to work.  Is there an easy way to switch the RPC format to JSON or some other format that doesn't have this issue?

When you use IsSerializable then GWT will fallback to an old serialization policy which does not require a RPC policy file. I am not very familiar with that old serialization policy but it is considered legacy.

You can not change the way GWT-RPC works but you could stop using GWT-RPC and switch to REST / JSON using https://resty-gwt.github.io . As its API on client side is pretty similar to GWT-RPC it should be easy to migrate. On server side you would use some JAX-RS 2.0 implementation like Jersey or RESTEasy (or others).

-- J.

[Vitaly Litvak]

I have spent four hours yesterday investigating the issue with serialization. In my case all objects do implement 'IsSerializable', which should force GWT to use the old serialization. And it works fine on the server side, but on the client side (i.e. in web browser) it looks like it does not know about the current used serialization policy and fails deserializing. After hours of reverse engineering I found out that `StandardSerializationPolicy` adds some array to the serialized object, which is expected to appear on the client side. But `LegacySerializationPolicy` does not add such array, which looks like the reason of failure on the client side.

It does not happen for all classes of objects in my case, but a particular one of them in has failed for sure. I don't know whether this is a bug or not, but finally I used solution from this answer: http://stackoverflow.com/a/25025144/1627984 . I am using latest publicly available at the moment of writing stable version of GWT 2.7.0. You can find my change in this commit of github: https://github.com/vitalidze/traccar-web/commit/1c7f257f93fab8e76dc2b6606cc4cc5ea7136136

Hope this helps.

Kind regards, Vitaly Litvak.

четверг, 9 июля 2015 г., 18:54:29 UTC+3 пользователь dhoffer написал: