unleash / unleash-proxy Goto Github PK

Today ETag header is automatically calculated by express based on the payload. We should instead use the SDK updated event and generate this id in the proxy. This would allow us to provide the proxy SDKs with a 304 modified fast, without having to evaluate all feature toggles in memory.

Note: We would also need to consider the query params as part of the produced hash.

If the json blobs gets large it can be smart to add some compression on the fly.

https://www.npmjs.com/package/compression can help with this!

Describe the bug

Configured our proxy server with the following

cors: {
        origin: 'http://localhost:3000'
    }

When making the initial request on page load for the flags, we get a perfect 200 with the header

Access-Control-Allow-Origin: http://localhost:3001

as expected, browser is happy.

Now, on a refresh request 30 seconds later (determined by refreshInterval) the same request is made with an extra header, something like

if-none-match: W/"101-w8M2PbyIXvu4DpZVMs3eAhoAXXU"

which I assume is just meant to save on compute by looking at a cache id. No problems

But the response we get (with a 304 as expected) does not have the CORS header like the original response has

Access-Control-Allow-Origin: http://localhost:3001

In fact, it has no CORS headers at all. This makes the browser unhappy and we end up with a failure every time it tries to refresh.

Steps to reproduce the bug

1. Set the cors origins to be some value on the proxy server
2. Make a request with Postman to get the toggles using a client id
3. Note that the CORS origin you specified is set in the response header: Access-Control-Allow-Origin
4. Take the ETag header from that response, and stick it in the request headers with the key if-none-match
5. Make the request again, which should be a status code 304.
6. Evaluate the headers, and notice the same CORS header is not included in the second response. Access-Control-Allow-Origin

Expected behavior

Expected behavior should be to still respond with a 304 HTTP code, but the requested CORS config should also be put on the response from the proxy server.

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

latest

Subscription type

Open source

Hosting type

Self-hosted

SDK information (language and version)

No response

Describe the bug

I'm running a proxy on my local that is connected to gitlab. When I use the code below to connect from a local express the output is Response was not statusCode 2XX, but was 401

try {
    const unleashProxy = createApp({
      unleashUrl: "http://localhost:3000/proxy",
      unleashApiToken: "not needed for gitlab",
      clientKeys: ["secret"],
      refreshInterval: 10000,
      logLevel: "debug",
    });
} catch (error) {
  console.error(error);
}

When trying to connect from postman to http://localhost:3000/proxy with the header {authorization: secret} the response is what I expected

{
    "toggles": [
        {
            "name": "logo_banner",
            "enabled": true,
            "variant": {
                "name": "disabled",
                "enabled": false
            }
        }
    ]
}

I'm assuming that the header isn't populated in the client but I'm not sure why.

Steps to reproduce the bug

No response

Expected behavior

No response

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

No response

Subscription type

Open source

Hosting type

None

SDK information (language and version)

"@unleash/proxy": "^0.13.1"

Add support for log level.

It could be good for resilience if serverside SDKs could connect to Unleash via the Unleash Proxy.

Hey,

I would like to add a new logger that addresses a GELF endpoint. I think this one would be useful in a professional environment, where GrayLog is often used as the central log management. However, I have some questions:

• First, would something like this even be desired?
• I would create a new folder src/logger and separate the corresponding loggers into individual files in it. Agreed?
• Currently it is not possible to choose a different logger for dockerimages. I would also change that in the move by allowing a string to select the logger to use. options.logger would of course be preserved for node.js runtime environments. The information needed for GELF I would then also want to query for Docker via environment variables. For node.js there will be an option/config array.

Looking forward to a reply! 😊

Describe the bug

Suppose we have Projects A and B declared on Unleash, each containing a few feature toggles.
We also have Environments 1 and 2.

Project A is enabled for Environments 1 & 2.
Project B is enabled only for Environment 1.

Steps to reproduce the bug

1. When requesting the list of feature toggles from the Proxy API for Environment 1, we get all feature toggles, from both Projects A and B, which works as expected
2. But the same thing applies for Environment 2 as well, we receive all feature toggles from both Projects A and B, even though only Project A is enabled for Environment 2

Expected behavior

When requesting feature toggles for Environment 2, only the toggles from Project A should be returned

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

4.19.2

Subscription type

Enterprise

Hosting type

Self-hosted

SDK information (language and version)

No response

We are trying to deploy unleash proxy with AWS Lambda.

The example of handler function is the following

import { createApp } from '@unleash/proxy';
import * as serverless from 'serverless-http';

export const proxyHandler = async (event, context) => {
  const app = createApp({
    unleashUrl: process.env.UNLEASH_URL,
    unleashApiToken: process.env.UNLEASH_API_TOKEN,
    clientKeys: ['some-secret'],
    refreshInterval: 1000,
  });

  const handler = serverless(app);

  return handler(event, context);
};

The problem is that we should wait for the 'ready' event to be triggered before ‘wrapping’ the app for serverless use.

I have seen an approach in library's examples when passing a client as a second argument to the createApp function and making client.emit('ready') after, but the Client class is not exported by the library so this is not possible for us.

Please, can you help me with an answer whether there's a good solution to wait for/check the proxy to be ready to receive traffic.

Describe the bug

I'm getting an error when running unleash proxy behind a lambda function of it not being able to use a functions utils.forOwn. I'm running the proxy behind a lambda function using the serverless-http package.

Steps to reproduce the bug

1. Setup an http lambda function
2. Write this code

import unleash from '@unleash/proxy';
import { LogLevel } from '@unleash/proxy/dist/logger';
import { APIGatewayProxyHandlerV2 } from 'aws-lambda';
import serverless from 'serverless-http';

const app = unleash.createApp({
  unleashUrl: process.env.UNLEASH_URL,
  unleashInstanceId: process.env.UNLEASH_INSTANCE_ID,
  unleashAppName: process.env.UNLEASH_APP_NAME,
  clientKeys: [process.env.UNLEASH_PROXY_CLIENT_KEYS!],
  unleashApiToken: process.env.UNLEASH_API_TOKEN,
  refreshInterval: 1000,
  logLevel: LogLevel.debug,
  enableOAS: true,
  proxyBasePath: '/unleash',
});

export const handler: APIGatewayProxyHandlerV2 = serverless(app);

3. Make any /unleash/proxy call

Expected behavior

A list of toggles

{
  "toggles": [
    {
      "name": "string",
      "enabled": true,
      "impressionData": true,
      "variant": {
        "name": "string",
        "enabled": true,
        "payload": {
          "type": "string",
          "value": "string"
        }
      }
    }
  ]

Logs, error output, etc.

{"error":"Whoops! We dropped the ball on this one (an unexpected error occurred): utils.forOwn is not a function"}

Screenshots

No response

Additional context

I'm utilizing the sst framework, hosting the endpoint behind a /unleash/{proxy+} endpoint through an AWS Api Gateway HTTP API

Unleash version

0.10.4

Subscription type

Open source

Hosting type

Self-hosted

SDK information (language and version)

No response

Currently it is not possible do define the instanceId that unleash-proxy is using in its unleash-client.
unleash-proxy generates a random instanceId that can not be overwriten in any way.

This makes it impossible to use unleash-proxy with a GitLab Managed Unleash Instance.
GitLab uses instanceId's as a way of identifiying different users and requires you to use a specific instanceId provided by them.

It would be awesome if you could make the instanceId configurable, for example via an environment variable.

Describe the feature request

#87 introduced the notion of ContextEnrichers, which take the context of feature toggle evaluation modify it in some meaningful way. The use case of #87 is built around using fields that are already part of the context from the start.

To support more use cases, it would be helpful to pass the full request to context enrichers, so further custom information can be pulled from it into the context.

Background

Taking only fields from the existing context to enrich it is really limiting. This is especially true if you run the unleash-proxy embedded in a node application that already preprocesses the request a bit. Imagine running an application with authentication and having session information at hand (at req.user).

You would want to provide the user information as part of the context to use it in strategies. Without having access to the request, this is not possible. A workaround could only be knowing which requests unleash-proxy handles and how the context is transferred in each of them (req.query, req.body), and adding the fields there via a custom middleware, completely sidestepping the context enrichers in an honestly rather fragile way.

Solution suggestions

Enhance the ContextEnrichter interface to consume a Request. Pass the current req to the enrichContext function, so it can provide it to the context enricher chain.

This depends partly on #109, which makes sure enrichContext is actually called consistently across use endpoints

Hi,

I saw that it's possible to send a POST request with context information to the proxy, but when I try with Postman, I got an error

<pre>TypeError: Cannot read properties of undefined (reading &#39;map&#39;)<br> &nbsp; &nbsp;at Client.getDefinedToggles (C:\private\git\node_modules\@unleash\proxy\dist\client.js:75:28)<br> &nbsp; &nbsp;at UnleashProxy.lookupToggles (C:\private\git\node_modules\@unleash\proxy\dist\unleash-proxy.js:61:41)<br> &nbsp; &nbsp;at Layer.handle [as handle_request] (C:\private\git\node_modules\express\lib\router\layer.js:95:5)<br> &nbsp; &nbsp;at next (C:\private\git\node_modules\express\lib\router\route.js:137:13)<br> &nbsp; &nbsp;at Route.dispatch (C:\private\git\node_modules\express\lib\router\route.js:112:3)<br> &nbsp; &nbsp;at Layer.handle [as handle_request] (C:\private\git\node_modules\express\lib\router\layer.js:95:5)<br> &nbsp; &nbsp;at C:\private\git\node_modules\express\lib\router\index.js:281:22<br> &nbsp; &nbsp;at Function.process_params (C:\private\git\node_modules\express\lib\router\index.js:335:12)<br> &nbsp; &nbsp;at next (C:\private\git\node_modules\express\lib\router\index.js:275:10)<br> &nbsp; &nbsp;at Function.handle (C:\private\git\node_modules\express\lib\router\index.js:174:3)</pre>

My Payload
{"userId":"test"}

Best regards
Meex

When using unleash proxy docker image, it is not possible to configure it to allow self signed certificates, I have tried using the environment variables NODE_EXTRA_CA_CERTS and NODE_TLS_REJECT_UNAUTHORIZED, both doesn't appear to stop the "request to https://gitlab.example.com/api/v4/feature_flags/unleash/000000/client/register failed, reason: self signed certificate in certificate chain" error.

The only workaround is to run the unleash proxy as a node js application and adding httpOptions: { rejectUnauthorized: false } in the createApp configuration

Example

const app = createApp({
    unleashUrl: 'https://gitlab.example.com/api/v4/feature_flags/unleash/000000',
    unleashInstanceId: '0xx-0x0_xxXXXXX0_xx0',
    unleashApiToken: 'xxxxx-xxxxxxxxxxxxxxxxxx',
    unleashAppName: "example",
    clientKeys: ['some-secret'],
    proxyPort: 3000,
    **httpOptions: { rejectUnauthorized: false }**
});

If the value for httpOptions.rejectUnauthorized can be read from the Environment variables, then we can use the unleash proxy with the provided docker image

Hello again,

It is not super clear that UNLEASH_PROXY_SECRETS corresponds to clientKey when creating the client from the JavaScript Proxy SDK.

To make it easier to get started, maybe an example in the README after the list of Proxy SDKs might clarify? Or just mention that the secret should go in clientKey.

Or even change clientKey to proxySecret?

Currently the proxy has a simple http API.

In environments already leveraging graphql it could be beneficial to expose a graphql API as well.

I envision companies would be leveraging graphql stitching to make it performant for clients.

It should be optionally loaded.

👍🏼 If you think this is a good idea.

Would be the default for the docker distribution. Will heavily improve performance.

Describe the bug

Is it possible to add configuration option to disable prometheus endpoints, like one the unleash API server? This can potentially expose sensitive underlying host information.

Endpoint added in #78

Steps to reproduce the bug

No response

Expected behavior

No response

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

No response

Subscription type

No response

Hosting type

No response

SDK information (language and version)

No response

We are trying to implement Unleash in my organization. We have deployed the Unleash server internally, and it listens on an internal HTTPS address. The Unleash proxy is therefore unable to connect to it, since it does not have the root CA certificate for our internal addresses. The Unleash proxy shows this error:

ERROR: FetchError: Unleash Repository error: request to https://internal.address/api/client/features failed, reason: self signed certificate in certificate chain

They way we normally work around this is by adding our local CA certificate in our docker images. However, this is not possible to do with the Unleash Proxy because the running user does not have root permissions, so it cannot make any modifications .

A method or some documentation on how to work with custom CA certificates should be added, for situations such as this.

Thanks!

As of now, unleash-proxy is a suitable solution for one of my use cases i.e. fetch enabled features for a context. Let's say I have a context property (constraint) of location on features A, B, and C. With unleash-proxy in place, I can easily find if A, B, and C are enabled on location, say X.

Extending to it, I have another use case where I want to be able to enable/disable a feature for a particular context (constraint). For instance, ideally, given a feature name and constraint's contextName and value, I want an API that would internally fetch that feature by name, iterate over all of its strategies, and for each strategy, iterate over all the constraints, and then finally add the value to the list of values of that constraint.

Right now, I am handling all of this logic on my end using the following steps:

1. Get feature by name (unleash-server API call)
2. Iterate over strategies and constraints of the fetched feature object, updating the payload, and then updating the feature (unleash-server API call).

Ideally, these responsibilities should not be on consumer's end because the logic is a bit complex and involves two network requests.

Hi,

I've set up an Unleash instance and have confirmed that it works by using Postman. When I hit https://unleash-dev.innago.com/api/client/features I get a 200 OK with the following response:

{
	"version": 2,
	"features": [
		{
			"strategies": [],
			"enabled": false,
			"name": "testing-toggles",
			"description": "Temporary flag for testing using Unleash for release toggles. To be deleted once experiments are done.",
			"project": "default",
			"stale": false,
			"type": "release",
			"variants": []
		}
	],
	"query": null
}

I've also setup a proxy. But when I hit https://unleash-dev-proxy.innago.com/proxy I receive a 200 OK with the following payload:

{
	"toggles": []
}

In both of the above API calls I do not pass a request body and only set the Authorization header with the proper token.

To try and debug this, I have set the log level on the proxy to debug and here is what the logs show when I'm hitting it:

INFO: Get enabled feature toggles for provided context [ { remoteAddress: '::ffff:10.42.1.157', properties: {} } ]

And here is part of my YAML file:

spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      workload.user.cattle.io/workloadselector: apps.deployment-innago-dev-innago-dev-unleash-proxy
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: innago-dev-unleash-proxy
        client: innago
        environment: dev
        workload.user.cattle.io/workloadselector: apps.deployment-innago-dev-innago-dev-unleash-proxy
    spec:
      affinity: {}
      containers:
      - env:
        - name: UNLEASH_PROXY_SECRETS
          value: REDACTED
        - name: UNLEASH_URL
          value: https://unleash-dev.innago.com/api
        - name: UNLEASH_API_TOKEN
          value: REDACTED
        - name: LOG_LEVEL
          value: debug
        image: unleashorg/unleash-proxy
        imagePullPolicy: Always
        name: container-0
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

What could cause the proxy to return an empty toggles array?

Describe the feature request

Add support to configure refresh interval jitter.

Background

Having all proxy instances send metrics at the same time can put uneven load on the server, that would much easier to handle if there was a jitter.

Solution suggestions

Add a refreshIntervalJitter config option.

https://docs.getunleash.io/advanced/custom_activation_strategy

Describe the bug

When providing a proxyBasePath, it must start with a leading slash to work correctly. The example in the docs does not have a leading slash.

Mentioned in this Slack thread.

Steps to reproduce the bug

1. Run the proxy as via Node.js
2. Specify some/base as the base path
3. try to curl http://localhost:3000/some/base/proxy
4. Get a 404

Expected behavior

I'd expect the proxy to "do what I mean". Whether I use a leading or trailing slash in a path section shouldn't matter. These things always catches someone off guard, and in this case I really can't see any reason why it should matter.

In other words, regardless of which of the following options you provide, the result should be the same (/base/path/proxy):

• /base/path/
• /base/path
• base/path/
• base/path

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

No response

Subscription type

No response

Hosting type

No response

SDK information (language and version)

0.10 of the Proxy

Hi

I deployed unleash and postgress as described here:
https://hub.docker.com/r/unleashorg/unleash-server

I logged into unleash using 'admin' and 'unleash4all'.
i created an api token as admin.

i then ran unleash-proxy as documented using the token.

docker run    -e UNLEASH_PROXY_SECRETS=some-secret    -e UNLEASH_URL=http://192.168.122.195:4242/api/    -e UNLEASH_API_TOKEN=728934fd84bb7926ecd5367602fe5efc3550c66778b210d978576254    -p 3000:3000    unleashorg/unleash-proxy
Unleash-proxy is listening on port 3000!
ERROR: Error: Unleash Repository error: Response was not statusCode 2XX, but was 401 
ERROR: Error: Unleash Repository error: Response was not statusCode 2XX, but was 401 

hitting the interface http://192.168.122.195:4242/api/ returns

{"type":"password","path":"/auth/simple/login","message":"You must sign in order to use Unleash","defaultHidden":false}

Launch my application with following error:

***/node_modules/@unleash/proxy/dist/config.js:44
    return resolveStringToArray(tags)?.map((tag) => {
                                      ^

SyntaxError: Unexpected token '.'
    at wrapSafe (internal/modules/cjs/loader.js:915:16)
    at Module._compile (internal/modules/cjs/loader.js:963:27)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (***/node_modules/@unleash/proxy/dist/app.js:11:18)
    at Module._compile (internal/modules/cjs/loader.js:999:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1027:10)
    at Module.load (internal/modules/cjs/loader.js:863:32)
    at Function.Module._load (internal/modules/cjs/loader.js:708:14)
    at Module.require (internal/modules/cjs/loader.js:887:19)
    at require (internal/modules/cjs/helpers.js:74:18)
    at Object.<anonymous> (***/node_modules/@unleash/proxy/dist/index.js:7:15)
    at Module._compile (internal/modules/cjs/loader.js:999:30)

I think the issue is causing by the optional chaining, it's not supported on Node v12. (supported from v14)

In order to successfully load custom strategies inside docker you will currently need to also bundle the unleash-client dependency, like this:

npm init -y
npm install unleash-client

Now you should be able to load a custom strategy like this in docker:

docker run \
   -e UNLEASH_PROXY_SECRETS=some-secret \
   -e UNLEASH_URL=https://app.unleash-hosted.com/demo/api/ \
   -e UNLEASH_API_TOKEN=56907a2fa53c1d16101d509a10b78e36190b0f918d9f122d \
   -e UNLEASH_CUSTOM_STRATEGIES_FILE=/config/toggle-strategies.js \
   --mount type=bind,source="$(pwd)"/config,target=/config \
   -p 3333:3000 \
   unleashorg/unleash-proxy

And in the local directory in ./config/toggle-strategies.js I have:

const unleash = require('unleash-client');

class WorkspaceStrategy extends unleash.Strategy {
  constructor() {
    super('fy-workspace');
  }

  isEnabled(parameters, context) {
    return parameters['fy-workspace-id'].includes(context['fy-workspace-id']);
  }
}

module.exports = [new WorkspaceStrategy()];

We should not require the user to also add the unleash-client dependency because we already have this inside the proxy. We need to find a way to reuse the loaded dependency when loading these custom strategy implementations from a mounted folder.

What license is the proxy released under?

Also please consider adding a LICENSE file. Thank you!

The docker file merely runs dist/server

but server just defines a start function

we need a small example folder where you import the project (or yarn install it) and then run it similar to the example

Describe the feature request

Currently, the proxy endpoint returns only toggles evaluated as enabled by the Proxy for the current user, as stated inside the docs https://docs.getunleash.io/sdks/unleash-proxy#payload.
It there any particular reasoning for this design choice?

Background

In our flows we would need to know if the Proxy performed a proper evaluation to disabled OR if the Unleash instance doesn't even have the queried toggle defined.

Solution suggestions

Can this be achieved, if not through the default proxy endpoint implementation, then maybe by using either a different endpoint or a query param? Subsequently, can this be added inside the Android Proxy SDK and the rest of the SDKs (https://docs.getunleash.io/sdks/unleash-proxy#how-to-connect-to-the-proxy)?

Describe the bug

If you create a custom strategy, and try to access a property of undefined during the isEnabled method, the entire call for getting features given a context returns a 404 - which is a very strange response. I would expect it to at least log the error, or throw a 500. Had me chasing reverse proxy/cache-ing issues for three-four hours 😂

Steps to reproduce the bug

Create a custom strategy that accesses a property of undefined. Not the notAField in the return statement, this will surely throw a 'cannot access property accountId of undefined

You could also probably just throw an Error in the function as well and get the same result, though I did not test that.

const { Strategy } = require('unleash-client');

class AccountsStrategy extends Strategy {
    constructor() {
        super('Accounts');
    }

    isEnabled(parameters, context) {
            return parameters.accountIds.includes(context.notAField.accountId);
    }
}

module.exports.AccountsStrategy = AccountsStrategy;

Now, register that custom strategy, and make a call to the proxy with a feature configured to be using that custom strategy.

The app will respond with a 404 Not Found error.

Expected behavior

I'd expect this to fail a little more noticeably, or at least log the exception and return false for the feature. Not a random 404 that has nothing to do with the logic of the code.

Logs, error output, etc.

Setting log level to debug would show the context of the user's request before returning a 404, so I knew it was getting routed properly. 


INFO: Get enabled feature toggles for provided context [
  {
    appName: 'myApp',
    environment: 'production',
    userId: 'myUserId',
    remoteAddress: '::1',
    properties: { accountId: 'validAccountId' }
  }
]

### Screenshots

_No response_

### Additional context

This happened on the Node.js version of the self-hosted proxy, not the Docker one. Was able to reproduce in the cloud as well as locally. 

### Unleash version

latest

### Subscription type

Open source

### Hosting type

Self-hosted

### SDK information (language and version)

Was connecting to the proxy via the Javascript client SDK

We should not call start in index.ts and move it to a separate file (start-server.ts) which also should be the main entry point in package.json.

Also docker needs to call start-server.js

today we have a default for CORS. It could be good if the customers was allowed to configure their custom CORS header when needed.

Hello,

I'm trying to set up a local unleash server with the unleash proxy. However, I'm facing this error when running unleash-proxy:
ERROR: FetchError: Unleash Repository error: request to http://localhost:4242/api/client/features failed, reason: connect ECONNREFUSED 127.0.0.1:4242

I started the unleash-docker following these instructions: https://github.com/Unleash/unleash-docker#work-locally-with-this-repo

And I'm running unleash-proxy with this:
docker run -e UNLEASH_PROXY_SECRETS=some-secret -e UNLEASH_URL=http://localhost:4242/api/ -e UNLEASH_API_TOKEN="*:development.03b484052e9244c40ec4080216c4f00fcb3ef5e2c995a4468814e3bf" -p 3000:3000 unleashorg/unleash-proxy

How can I troubleshoot this error?

Thanks in advance.

When i run the unleash-proxy in a nodejs process where i also want to read toggle states, how should i query them?
I see that there is an option to replace fetch in unleash-proxy-client-js but is it prossible to query the proxy without making an extra http request?
I see the second argument of createApp() is client, but it's not documented yet. Would it be safe to use that?

Also, thanks a lot for this great tool! ❤️

Hello, thanks for providing!

I'm running another service at port 3000 so tried starting the proxy like so:

docker run \
   -e UNLEASH_PROXY_SECRETS=some-secret \
   -e UNLEASH_URL=https://app.unleash-hosted.com/demo/api/ \
   -e UNLEASH_API_TOKEN=56907a2fa53c1d16101d509a10b78e36190b0f918d9f122d \
   -p 3333:3333 \
   unleashorg/unleash-proxy

However, it returns:

Unleash-proxy is listening on port 3000!

And it's not just the message that is wrong, I think, because:

$ curl http://0.0.0.0:3333/proxy -H "Authorization: some-secret"  

curl: (52) Empty reply from server

Whereas if I start with -p 3000:3000 I get some nice flag config back.

When i try to install the @unleash/proxy package into an Typescript project. My compiler is complaining that there are no type definitions for this package.

TS7016: Could not find a declaration file for module '@unleash/proxy'. '/path-to-project/node_modules/@unleash/proxy/dist/index.js' implicitly has an 'any' type.   Try `npm i --save-dev @types/unleash__proxy` if it exists or add a new declaration (.d.ts) file containing `declare module '@unleash/proxy';`

When i look into the package in my node_modules folder i can confirm, that there are no .d.ts files.
Defining the module by myself like this:

declare module '@unleash/proxy' {
    export * from '@unleash/proxy';
}

only leads to an error saying that there are no types for package compression (a dependency of @unleash/proxy)
As this is not my direct dependency, i actually dont want to install the types for this..

Would it be possible to publish theses types within the package? This would make it alot easier to use it with typescript.

Hi, amazing project and company.

So, I am looking for excuses to code Deno, and I wondered whether I could port this proxy to it and see performance gains. However, we'd need to measure performance first. Are you planning on this? Already some tool you plan to use?

Cheers!

It's quite common to run services behind proxies of some kind which removes the users IP address. We should allow users of the proxy to trust proxies to automatically get the users IP added.

https://expressjs.com/en/guide/behind-proxies.html

An official Helm chart would simplify deployments to Kubernetes.

Describe the bug

Hi!

When I try to use PROXY_BASE_PATH: "base-path" with ENABLE_OAS: "true" all of the requests to unleash proxy which I make using OpenAPI interface return 404.

<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>Cannot GET /base-path/base-path/proxy</pre>
</body>
</html>

Seem like the reason for 404 is duplicated part /base-path in the url. Maybe there is some misconfiguration of OpenAPI when PROXY_BASE_PATH is used

Steps to reproduce the bug

I used similar docker-compose.yml:

version: '3.8'

services:
  unleash:
    image: unleashorg/unleash-proxy
    environment:
      ENABLE_OAS: "true"
      PROXY_BASE_PATH: "base-path"
      UNLEASH_PROXY_CLIENT_KEYS: $UNLEASH_PROXY_CLIENT_KEYS
      UNLEASH_URL: $UNLEASH_URL
      UNLEASH_INSTANCE_ID: $UNLEASH_INSTANCE_ID
      UNLEASH_APP_NAME: $UNLEASH_APP_NAME
      UNLEASH_API_TOKEN: $UNLEASH_API_TOKEN
    ports:
      - 3000:3000

Run it and then go to http://127.0.0.1:3000/base-path/docs/openapi/

If you try to execute any request using OpenAPI Interface, it returns 404 in response

Expected behavior

No response

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

No response

Subscription type

None

Hosting type

None

SDK information (language and version)

No response

Describe the feature request

Hey there,

Inside the getAllToggles api there is a logger usage:

this.logger.info(
            'Get all feature toggles for provided context',
            inContext,
        );

This log can be very spammy with high traffic, and it seems the purpose of this log is for debugging/troubleshooting, so I would like to suggest changing it to:

this.logger.debug(
            'Get all feature toggles for provided context',
            inContext,
        );

If it is accepted as a request for change I can submit a PR for it.

Background

No response

Solution suggestions

No response

In the code
const apiToken = req.header('authorization');
in the documentation
curl http://localhost:3000/proxy -H "Authorization: some-secret"

That's not going to work on *nix.

Provide a list of specific JWT token provider instead of a shared secret.

In my example, I'm building a single page application using Azure B2C as the user base. I envision that I can give this package some kind of public version of telling that it should accept all valid tokens from my JWT token provider. This would make this proxy more secure by not relying on having a shared secret with the website.

Describe the bug

Feature Flags have been created in the Gitlab repository named test-feature1 (for All Environments) and test-feature2 (for dev environments).

Unleash-proxy is configured with this repository - the following environment variables are set:

-env:
   -name: UNLEASH_ENVIRONMENT
     value:dev
   -name: UNLEASH_API_TOKEN
     value: some_gitlab_access_api_token
   -name: UNLEASH_PROXY_CLIENT_KEYS
     value: W0JHeVYSFwyBXEY7IV8BHogSx3L
   - name: UNLEASH_URL
     value: https://gitlab.domain/api/v4/feature_flags/unleash/8113
   - name: LOG_LEVEL
     value: info
   - name: UNLEASH_APP_NAME
     value: some_app_name
   -name: UNLEASH_INSTANCE_ID
     value: some_instance_id
   - name: JSON_LOGGER
     value: "true"

When I try to get Feature Flags from unleash-proxy I only get test-feature1 (For All Environments) and not for test-feature2 (for dev).

$ curl --silent unleash-proxy-app-dev.ingress-domain.lan/proxy -H "Authorization: W0JHeVYSFwyBXEY7IV8BHogSx3L" | jq
{
   "toggles": [
     {
       "name": "test-feature1",
       "enabled": true
       "variant": {
         "name": "disabled",
         "enabled": false
       }
     }
   ]
}

If you set the Feature Flags for test-feature2 to All Environments, then the query returns two Feature Flags.

test-feature1 (For All Environments) and test-feature2 (For dev) are both enabled.

How to get Feature Flag from request to unleash proxy for dev environment?

Steps to reproduce the bug

No response

Expected behavior

Should return flags for dev environments.

Logs, error output, etc.

No response

Screenshots

No response

Additional context

No response

Unleash version

0.13.1

Subscription type

Open source

Hosting type

Self-hosted

SDK information (language and version)

No response

To reproduce:

1. Use https://github.com/Unleash/unleash-android-proxy-sdk
2. When configuring the client, call enableMetrics()
3. Run proxy locally
4. See that metrics from proxy-sdk does get registered, and metrics.count(name: string, enabled: boolean) does get called
5. No POST to unleash /api/client/metrics happens

So this bug might be in how we instantiate the metrics class, or it's a bug in the node-client-sdk.

README.md has a UNLEASH_CLIENT_KEYS option which is supposed to become supported since version 0.5. But the docker hub latest image version is 0.4.0. So the documentation is ahead of the docker hub image version.