Missing Bearer Token On Proxy Assets: Solutions & Discussion

Hey guys! Today, we're diving deep into a tricky issue: missing bearer tokens when dealing with proxy assets in the Equinor Fusion Framework. This is a crucial topic for anyone working with external applications and the Fusion Framework, so let's break it down, explore the problem, and discuss potential solutions. We'll keep it casual and focus on understanding the core concepts and how to tackle this challenge effectively. This is a pretty in-depth issue, so buckle up!

Understanding the Issue

Bearer token issues arise when loading external application service source code using the @equinor/fusion-framework-vite-plugin-spa. The service worker is designed to add a bearer token to the initial request. It then rewrites this request to the local proxy route, which corresponds to the import.url for the loaded script. This is all well and good for the initial load, but the trouble starts when the loaded script has assets or relies on code splitting. In these scenarios, subsequent requests often bypass the service worker. This means they go straight to @equinor/fusion-framework-vite-plugin-api-service without the necessary bearer token.

This lack of a bearer token can lead to authorization failures, preventing the application from accessing protected resources. Imagine loading an app that needs to fetch data from an API – if the bearer token is missing, the API will likely reject the request, and the app won't function correctly. The core of the problem lies in how the service worker handles the initial request versus subsequent requests for assets and code splits.

The service worker's primary responsibility is to intercept network requests and potentially modify them. In this case, it's adding the bearer token for authentication. However, the current implementation doesn't consistently apply this token to all requests originating from the external application. This inconsistency is what leads to the “missing bearer token” problem. So, how do we ensure that every request, including those for assets and code splits, carries the necessary authentication information? Let's explore some ways to reproduce this issue and then dive into proposed solutions.

Reproducing the Problem

To really understand this, let's look at how to reproduce the issue. The easiest way is to use the command-line interface (CLI) and load an external application. For example, you can use the ffc portal dev command and navigate to /apps/some-app-with-assets. The key here is to load an application that has assets or utilizes code splitting. Once the application is loaded, you'll notice that the resources loaded from the initial app script are missing the bearer token in their headers.

This lack of a token can be verified by inspecting the network requests in your browser's developer tools. You'll see that the initial request made by the service worker includes the token, but subsequent requests for assets (like images, CSS files, or additional JavaScript chunks) do not. This discrepancy highlights the core of the issue.

By reproducing the problem, you can clearly see the impact of the missing bearer token. Requests fail, resources don't load, and the application's functionality is compromised. This hands-on approach helps solidify the understanding of the problem and the need for a robust solution. Now that we know how to reproduce the issue, let's explore some potential solutions to ensure those tokens are consistently included.

Proposed Solutions: Two Paths Forward

Okay, so we know the problem and how to make it happen. Now, let's talk solutions! We've got a couple of options on the table, each with its own set of trade-offs. Let's break them down.

Option 1: The Proxy-Host Token Set

Our first idea involves adding a proxy-host token set. Think of this as a little token vault specifically for each proxy host. We'd store and reuse tokens for a particular host if a request comes in without a bearer token. This sounds pretty straightforward, right? Well, there are a couple of things we need to watch out for.

How it works: The core concept is to create a mechanism that associates tokens with specific proxy hosts. When a request is made to a proxy host, the system checks if a token is already associated with that host. If not, it fetches or generates a new token and stores it. For subsequent requests to the same host, the stored token is automatically included if the request doesn't already have a bearer token. This ensures that resources loaded from the proxy host have the necessary authentication.

Potential pitfalls:

• Token Over-Application: Here's a big one. If we implement this, all requests to @equinor/fusion-framework-vite-plugin-api-service for that proxy-host will include a token. That might not be what we want! We need to be super careful about potentially over-applying the token and accidentally giving access where it's not needed. This could lead to security vulnerabilities if not handled carefully.
• Timing Issues: What happens if a request slips through before the service worker has a chance to rewrite it? If a request gets executed before it's