Unleash Edge does not reflect any custom hooks or logic added to the API

Describe the feature request

Unleash Edge should reflect any custom hooks used in the Unleash API

Background

I'm using the OSS version of the Node unleash-server and have been experimenting with Unleash Edge locally using the official docker image.

My API has the default API token middleware enabled (meaning that all requests require an API token), but includes a pre-router hook that allows for calls to be made to /api/client endpoints even if an API token is not included.

When using Unleash Edge, I'm able to connect and run everything just fine, but it disregards the custom hook and goes back to the default behaviour of requiring all requests to include an API token.

I'm unsure if this is a bug or intended behaviour (or user error on my part), but it effectively prevents any custom hooks from being executed when accessing the API through Edge.

Solution suggestions

Unsure of what the most effective solution would be for this, as I am unfamiliar with most of the Unleash/Edge operating logic.

One solution may be to let the API itself handle the authentication (either by default or just conditionally if a customAuthHandler, preHook or preRouterHook is specified). Of course, this may impact the performance and resilience of Edge's design.

Happy to hear proposals others may have, if any.

Hey @00Chaotic!

If I'm understanding you correctly, it sounds like you're wanting to allow Edge to connect to Unleash but you don't want Edge to require an API token when a downstream SDK connects?

Unfortunately, I'm not sure that's easily possible with Edge and I don't think it's something we'd want to support directly (you're always welcome to fork and extend!) The tokens that Edge uses are pretty deeply entwined in the way it works and Edge is really meant for secure, large scale production setups. To give you a sense of why this would be hard:

Edge uses the incoming token to determine project and environment so that it can return the correct toggles for a request
Edge needs a valid token(s) to sync to the upstream instance for the correct projects and environments, in a lot of cases this is dynamically determined, based on which tokens it's seen in during its runtime
Frontend api calls require this to determine the matching toggles for the API request
Edge also uses the tokens to store the relevant toggles in it's internal memory cache by project/environment
Metrics for incoming SDKs are stored and sent on a per project and environment basis (based off the token)
Likewise for persistent caches like Redis

However, Unleash itself also needs this information in the api/client/features endpoint to work out the correct set of toggles to return for a request (for OSS this is typically the difference between returning toggles for your production environment and toggles for your development environment). I'm guessing you've done something smart to handle that in your prerouter hook? Without token auth you risk leaking a whole bunch of potentially sensitive information so I would be very careful about using that setup in prod. Is there an important reason why you need Unleash to ignore incoming token auth?

I'm not sure Edge is a good fit for what you're trying to doing here, most of what Edge can do for you is based on information encoded in the token itself. Could you tell me a bit more about what you're trying to achieve and maybe I can suggest an alternative?

@sighphyre Thanks for getting back to me.

In our case, we were already using Unleash v3 and migrated to v5, which has meant that all our existing (and possibly future) toggles are in the default project and environment, leaving the other two OSS environments unused. We also have separate instances of Unleash for each of our environments (from before environments were added to Unleash), so we only really use the default environment for the time being. We do have plans to consolidate this down to just once instance but those plans have not yet been implemented.

In terms of security, our Unleash API is behind our own SSO proxy (not sure of the exact terminology to best describe it) so that the server is actually not accessible unless you're authenticated. This will obviously also be the case for when we implement Edge. While there are some thoughts on additionally using Unleash's normal auth further down the line, for the time being we just use the demo auth to allow essentially an open login as long as the employee/service is authenticated via our own proxy.

In terms of why we need the ability to allow requests that don't use API tokens, that is because we already have numerous services using our Unleash API, so in order to minimise disruptions and prevent the need for batch changes, we've implemented middleware that accepts API tokens, but also allows services that haven't migrated yet to continue functioning while their teams work on implementing the changes.

I understand that this may be an uncommon or even unique case, and it seems API tokens are a fundamental block of the way Edge is designed, so I don't expect changes to be made to Edge. We may just need to wait till all our client services have migrated to using API tokens before we implement Edge.

I'm happy for this issue to be closed if there is no further action to take or discussion to be had.

Thanks for the detailed response @00Chaotic, I have a much better understanding of what you're doing and why. That makes a lot of sense

We may just need to wait till all our client services have migrated to using API tokens before we implement Edge.

This would be my gut feel as well. We probably could work a hack here here but I suspect that's just going to cause more pain. Unless you're in desperate need of better scaling systems then I would just wait it out.

I'm trying to keep Edge as focused as possible on it's primary use cases, so I'm going to close this one. But absolutely feel free to grab us on our Slack if you need to talk about scaling

Unleash / unleash-edge