Is it possible to use JWT with TEdgeBrowser in c++?

by

Summary

A developer attempted to embed a JWT‑authenticated web application inside a C++Builder application using TEdgeBrowser, but discovered that the component provides no supported mechanism to inject custom HTTP headers (including Authorization: Bearer tokens) into navigation requests. This limitation prevents JWT‑based authentication flows from working as expected.

Root Cause

The failure stems from a fundamental limitation in the WebView2/TEdgeBrowser API:

  • TEdgeBrowser does not expose request‑interception hooks
  • No API exists to append custom headers to navigation requests
  • JWT authentication typically requires Authorization headers, which cannot be injected
  • WebView2’s CoreWebView2 only supports custom headers for WebResourceRequested events, not top‑level navigations

Why This Happens in Real Systems

This class of issue is common when embedding modern web apps into native shells:

  • Embedded browsers often restrict low‑level network control for security reasons
  • JWT‑based SPAs assume a full browser environment, not a constrained host
  • Native wrappers frequently lag behind the capabilities of the underlying engine
  • Developers expect “just load the URL” to work, but authentication flows require header manipulation that the wrapper does not support

Real-World Impact

When JWT headers cannot be injected:

  • The web app fails authentication immediately
  • Users see login screens or errors instead of the intended embedded UI
  • Developers waste time debugging the web app instead of the host application
  • Workarounds become necessary, increasing complexity and maintenance cost

Example or Code (if necessary and relevant)

Below is an example of how developers expect to set headers (but cannot with TEdgeBrowser):

// This is NOT supported by TEdgeBrowser
browser->NavigateWithHeaders("https://example.com", "Authorization: Bearer ");

This code is intentionally shown to illustrate the missing API.

How Senior Engineers Fix It

Experienced engineers work around the limitation using one of these patterns:

  • Use URL query parameters to pass a short‑lived token (if the backend supports it)
  • Inject the JWT into localStorage/sessionStorage via ExecuteScript before loading the app
  • Host a local proxy that adds the Authorization header and forwards requests
  • Switch to a different embedding technology (CEF4Delphi, QtWebEngine, etc.) that supports request interception
  • Modify the web app to support token bootstrapping via postMessage or a custom handshake

The most robust solution is typically:

  • Load a bootstrap page
  • Inject the JWT using JavaScript
  • Then navigate the embedded app using the injected token

Why Juniors Miss It

Less experienced developers often overlook:

  • The difference between browser navigation and XHR/fetch requests
  • That TEdgeBrowser is a thin wrapper, not a full browser API
  • That JWT authentication flows assume header-level control
  • That WebView2’s feature set is not identical to Chrome

They assume that generating a JWT is enough, without realizing that delivering it to the web app is the real challenge.

Leave a Comment