Vaadin 24 components blocked by Menlo Security?

Menlo Security provides remote browser isolation services that big financial organizations seem to use. People at one of these organizations are trying to use one of our applications, and certain UI components are not rendering, like the calendar component. Has anybody seen behavior like this and have figured out how to get around it?

If you’re able to reproduce the issue, you should check how exactly this manifests in the browser:

  • is there an error logged to the browser console?
  • is a network request returning with an error code?

My gut feeling is that this needs to be solved on Menlo’s side somehow, but I’m not familiar with the product.

Well, yes, thanks. We need to try more logging. Its happening on the PC of the partner manager who was running our product to certify it (couldn’t think of a worse time), and he’s in a locked down corporate environment we don’t have access to. If the problem were caused by Menlo, we would need this partner’s IT to request a fix. They ain’t going to listen to little old us. The guy who ran into the problem told us he didn’t really know where to start in their hierarchy to find somebody who would care enough to help.

thus I’m looking for other instances where these components are failing in the wild. Drop down lists and calendar control.

btw, I just learned this used v23 java components. We are going to try v24 components. Apparently typescript components would work, but would largely require a rewrite.

Hi,

Before starting to rewrite your code (it won’t have any affect)

  1. It’s pure configuration at the IT company.
  2. They are using apache guacamole as broadcaster for your Vaadin App.
  3. Vaadin uses atmosphere sockets for communication
  4. For historical reasons vaadin uses (for::) in rpc , so this produces a BAD JSON threat (BUT it’s not a threat,it’s advantage !!)
  5. 99.99% they are using Windows Server as RDP on top of Guacamole (by the way the will never admit that, because it’s open source and public domain)

So, simply
send them the above…

Now if you want to try your self
have a look at Kasm, download community edition, and see error if any

Now, if the security company will not help you out.
(the will probably won’t, not because they are bad people, they will probably have no idea what your are talking about)

Depends on your app three options you have :slight_smile:

The good, the bad and the ugly.

will start with the Ugly : wrap your app inside a javafx or swing app (with chrome browser), it will make like a desktop app. RDI (remote desktop isolation) will work better…

the Bad, ask the security company to send you specs of their product and try to adjust inside Vaadin Core… (very bad)

the good, if the product is important it will require some time and hard work, you can use JNI with c++, so all interactions beetween RDI is <> c++ and your vaadin app is free from his limits.

Note: while this is technically correct; it should not be the problem here. Otherwise the whole application won’t load instead of just a specific component.

Just an idea: are you using shortcuts or key listener on that date picker? Or other fields that aren’t displayed?

1 Like

hi @knoobie you are right, but i was pointing what could be considered as threat.

any way in RDI the UI is rendered on a remote web browser, so it’s not a Vaadin bug.

thanks, I’m thinking option 4 is to rewrite with React.js and not use Vaadin at all.

Its all vanilla. We created a test page with just the two problem components

https://component-test.pivoteq.com

It didn’t work in their corporate environment.

Out of curiosity… the Grid works? From a complexity point of view Grid > Date picker > Combobox, so I would have thought that one would also go over board…

But nevertheless, you could already narrow your the problem to those components… creating an issue in the web components repo on GitHub might be your next step so that the components team can take a loot at it, might be something totally trivial (hopefully)

Hi @tom.spitzer
Thank you for sharing the link

your situation is much much simpler then I thought

ASK THEM to ENABLE WEBSOCKETS

it’s disabled by default

That’s a good question, knoobie. I’m hesitant to open a ticket when I can’t say with certainty what environment it is executing in, and due to NDA I can’t say who. I think the environment is Menlo’s browser isoolation based on evidence I’ve seen but I could be wrong. We’re 99% certain that its some kind of browser isolation.

that we can probably ask for.

Just for completeness… we had a similar problem where a web application firewall had problems with websockets and we solved it by forcing the Vaadin application to use long polling instead.
I assume, this would also be viable here?

Hi, yes indeed.

It’s important to understand how this systems works.

they work like windows RDP or any VNC technology

In regular webapp, the user comes to your url and the server replay to him.

In “Isolated” apps : the user comes to your url and there is a “middle man”, so you send request to the middle man, and the middle man send request to the server and replay to user. same as proxy in servers, but, it’s broadcasting the webpage to you.

There need to be done some configuration on your side but mainly on the middle man.

In @tom.spitzer situation , the middle man does not transfer the requests to the server(eg vaadinapp) this is why the components does not render. (you see the textbox and the combobox but no data is rendered)

It’s usually proxy settings, websockets etc. and basically good willing of the System Administrators.

Another point for you @tom.spitzer : you didn’t install your app at your client. his sysadmin did it. Maybe it’s not connected to Melon Security at all.
Maybe he didn’t configure the proxy server right, and i will bet a beer its w-i-n-d-ows Server?

In rare cases, like in Military Environment, you need to create an double isolation.
so you take the VaadinApp, wrap it in c code (I think also go has the ability) and convert it to “Sandbox” … so your wrapper code speaks with the “middle man” in his own language…

My Point in all of this is one : Don’t get panic.

At the production stage the browser does not care how you wrote the code, and which technology you used. It understands Javascript & HTML.

Thanks, @ecohen280 . We are going to treat this as an IT issue. When we get a “real customer” that wants to use our product that shows evidence of the problem and is willing to work with us, we’ll try to figure out how to unblock it. In spite of the challenge, we did receive approval to go live, and will early access later this month and GA probably in July. We’ll see how it goes. All the input here was helpful in getting us to this point.

1 Like