Skip to content
Notifications
Clear all

Does the 'clientless' web access actually work for complex internal apps?

1 Posts
1 Users
0 Reactions
3 Views
(@jackson2m)
Estimable Member
Joined: 1 week ago
Posts: 67
Topic starter   [#8674]

I’ve been evaluating Appgate SDP for our multi-tenant ERP environment, where we have a mix of legacy web applications (Java applets, some requiring ActiveX back in the day), modern React-based admin portals, and a handful of thick-client applications that use web services for data exchange. The vendor’s documentation heavily promotes the ‘clientless’ web access feature as a zero-footprint solution for accessing internal tools from any browser, which conceptually aligns perfectly with our goal of reducing endpoint management overhead for our field and partner teams.

However, in my proof-of-concept lab, I’ve encountered significant rendering and functionality issues that go beyond simple compatibility mode fixes. The promise seems to be for relatively simple, stateless web apps, but our real-world stack presents several challenges:

* **Stateful Sessions & Complex JavaScript:** One of our primary inventory management dashboards uses long-polling WebSocket connections for real-time stock updates. The clientless session frequently times out or fails to re-establish these connections after a network blip, requiring a full reload and login.
* **File Upload/Download Workflows:** Several of our procurement apps require multi-file upload with client-side validation (checking file size, type) before submission. The clientless portal often strips or misinterprets the `multipart/form-data` encoding, leading to corrupted uploads.
* **Non-Standard Ports & Protocols:** A legacy vendor portal runs on a non-standard port and uses a custom authentication scheme that injects headers via a middleware component. Appgate’s gateway seems to rewrite certain headers, breaking the handshake.

My core question is whether these are limitations of the underlying tunneling technology (I suspect it’s essentially a sophisticated reverse proxy with DOM rewriting) or simply a matter of configuration. Has anyone in the community successfully deployed clientless access for similarly complex internal applications? Specifically:

* What were the specific application technologies (e.g., WebSocket implementations, specific JavaScript frameworks) that you got working reliably?
* Did you have to make any modifications to the applications themselves, such as adjusting CORS headers, session cookie settings, or absolute vs. relative URLs?
* Are there measurable performance penalties, particularly for applications that are highly interactive or transmit large datasets (like CSV exports or report generation)?

I am compiling a feature matrix comparing the clientless experience across several SDP/ZTNA vendors, and the operational viability of this mode is a critical column. Any detailed anecdotes or technical workarounds would be immensely valuable for my analysis.


Data over opinions


   
Quote