HTTP 404 on Vaadin 7 when accessed through a Juniper Secure Gateway (reverse proxy VPN)

[vaadin-bot]

Originally by cmcbrien

---

We are looking to deploy an internal application so that it can be made accessible to the outside world through our secure gateway. An example would be http://www.company.com/app/ (click on a button). A communication error will appear.

Appended is a network trace showing that some requests from the client succeed through the gateway while others cause a HTTP 404 response.

Here’s a snipit of a failed request:

URL /dashboard/UIDL/?v-sh=1080&v-sw=1920&v-cw=1920&v-ch=977&v-curdate=1365026143941&v-tzo=360&v-dstd=60&v-rtzo=420&v-dston=true&v-vw=1920&v-vh=977&v-loc=http%3A%2F%2Fdemo.vaadin.com%2Fdashboard%2F%23!%2Fdashboard&v-wn=dashboard-1047860588-0.031643264512902&v-wsver=7.0.1&v-uiId=1

Method: POST
Result: 404
Type: text/html
Received: 2.19 KB
Taken: 31 ms

---

Imported from https://dev.vaadin.com/ issue #11482

[vaadin-bot]

Originally by @wolfie

---

I've encountered an issue where having a proxy redirect from one URI structure to another leads to a communication error. I.e. visitor enters "http://server.com/foo" and that is proxied internally to "http://intra.server.com/bar". Changing the proxy to respond from "http://intra.server.com/foo" made the communcation work again.

Do you still have a chance to check whether this issue might be the same?

[vaadin-bot]

Originally by @wolfie

---

After consulting with others, this seems to be a bit wider a problem than the one I'm having. I'll make a separate ticket for myself.

[vaadin-bot]

Originally by @Artur-

---

If I remember correctly the Juniper issue is caused by an "URL obfuscation" feature of the firewall (http://www.juniper.net/techpubs/en_US/sa/topics/task/operational/secure-access-web-rewrite-browsing-options-specifying.html).

For example, if a user navigates to www.msn.com without selective rewriting or host name encoding enabled, the Secure Access Service displays an un-obscured URL in his Web browser’s address bar:

http://www.msn.com/

If you then enable selective rewriting, the Secure Access Service might display the following URL:

https://mycompanyserver.com/,DanaInfo=www.msn.com,SSO=U+

If you then enable host name encoding, and the same user navigates to the same site, he sees a URL in which the host name (www.msn.com) is obscured:

https://i5.asglab.juniper.net/,DanaInfo=.awxyCqxtGkxw,SSO=U+

The problem with the Juniper approach is that it rewrites some URLs on the fly but not all, e.g. the relative UIDL url sent by VaadinServlet to the client is not rewritten by Juniper. Because of this the UIDL request likely go to http://mycompanyserver.com/UIDL without the Juniper custom comma separated part. It's curious that the Juniper approach can work at all with web pages, for it to work 100% with Vaadin applications I guess Juniper would need to write a Vaadin plug-in in the same way it has flash, applet, pdf, ... plugins.

Should also be noted that the way of rewriting the URL is not secure for using for the whole internet as all sites have access to information of all other sites (same domain as all URLs are rewritten to the company internal host name). Juniper recommends (http://kb.juniper.net/InfoCenter/index?page=content&id=KB15799) the feature to only be enabled for company internal sites. Also I don't see why you would enable it for internal sites that you want to publish to the internet?

Summary: I don't see how Vaadin could fix this problem in the Juniper product.

[vaadin-bot]

Originally by leroy.nicolas

---

This ticket was closed 13 months ago. Since then, have you other information that could be useful to unblock this issue ?

[vaadin-bot]

Originally by 35niavlys

---

Edit: more complicate that I thought

JS files created in the widgetset folder are modified on the fly by the juniper proxy. It seems that it is able to do it on some requests and not on some others...

[vaadin-bot]

Originally by 35niavlys

---

I finally found a solution ! You need to compile the widgetset with the option "-style PRETTY" in order to have a "simpler" js file to translate by the proxy.

ThemeResource inside a button doesn't seem to work but we can set an icon with css...

EDIT : Only works with IE11...

[stale[bot]]

A lot of tickets have been left hanging in the issue tracker through the years. Some of them are still relevant, some of them have been fixed a long time ago and some are no longer valid. To get a better look on what is important and still relevant, we are closing old tickets which have not been touched in a long time. No further work will be done on this ticket. If the ticket seems to be still actual, please verify the problem existence over latest framework version and then open a new ticket in vaadin/framework with all the suitable information.

[johannest]

We have case where this issue or very similar happens with Pulse Secure SSL based VPN and Google Chrome. Some of the requests are done without that ,DanaInfo=url,SSL+ postfix. For example most (if not all) UIDL requests fail and also loading the initial styles.css fails. I created a simple test project without vaadin that can be used to try to reproduce the issue: https://github.com/johannest/servelt-xhr-test

[johannest]

One possible explanation could be that VPN doesn't always detect URLs created by string concatenation, and thus fails to rewrite those.

[stale[bot]]

Hello there!

We are sorry that this issue hasn't progressed lately. We are prioritizing issues by severity and the number of customers we expect are experiencing this and haven't gotten around to fix this issue yet.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!