Getting an empty `toggles` array about unleash-proxy HOT 11 CLOSED

Actually i would not consider this solved - i stumbled across the same issue and i think to me this is a major bug inside the proxy implementation.

If the server supports admin keys which allow multiple environments
and the client sdks (e.g. javascript) allow to explictly to set a context (and also overwrite the proxy context - if not specified otherwise in the proxy config), than the proxy should not ignore the environment passed along...

The documentation even implies that not setting an environment explicity for the proxy allows the client SDK to "OVERRIDE" or set the context itself?

If set this will be the environment used by the proxy in the Unleash Context. It will not be possible for proxy SDKs to override the environment if set.

So looking at a configuration of the client SDK using the environment flag:

let config = {
      url: 'https://xxx/proxy',
      clientKey: 'proxy-client-key',
      appName: 'XXX',
      project: 'XXX',
      environment: "why should i be able to set this inside a client sdk if its getting ignored by the proxy..",
    }; 

the proxy even seems to honor the environment in the incoming request:

Unleash-proxy is listening on port 3000!
INFO: Successfully synchronized with Unleash API. Proxy is now ready to receive traffic. 

INFO: Get enabled feature toggles for provided context [
  {
    environment: 'development',
    remoteAddress: 'XXX',
    properties: { project: 'XXX' }
  }
]

So why should one introduce admin keys (allowing multiple environments) which can be called server side just fine:

curl "https://XXX/api/admin/features?project=XXX&environment=development" \ -H 'Authorization: YOUR_ADMIN_TOKEN'

curl "https://XXX/api/client/features?project=XXX&environment=development" \ -H 'Authorization: YOUR_ADMIN_TOKEN'

returning the expected toggles while the proxy is ignoring the client SDK querying for a specific environment?

I think you should either remove the environment flag in the client SDKs completely as the proxy-instance url will be the reference to the environment anyways when using multiple proxy instances, or properly handle environments to align with the server and client sdks.

from unleash-proxy.

does that mean that I have to deploy a separate proxy for each environment, or is there a way to use the same proxy for both development and production environments?

This is possible if you create a custom express app and uses the proxy as a router you mount on separate paths.

from unleash-proxy.

Hey, @janknobloch! Thanks for the input. You address some valid concerns here. I'll bring this up with the team. In the meantime, let me try and elaborate a bit, because it is a bit of a mess as it stands 🙈

The SDK environment configuration property and Unleash's environments

I think you should either remove the environment flag in the client SDKs completely as the proxy-instance url will be the reference to the environment anyways when using multiple proxy instances, or properly handle environments to align with the server and client sdks.

The environment configuration property is actually a holdover from earlier versions of Unleash. Prior to v4.3, Unleash didn't have any real notion of environments outside of this context field. However, with 4.3 came the environments feature, which is intended to replace the environment context field. (Before 4.3, the context field was the only way to give features different configurations per environment, but we no longer recommend that approach.)

As it stands, the environment property is a holdover from earlier versions. It is likely that we'll remove this field entirely in the next major version of Unleash.

With the introduction of the environments feature, we also changed how API tokens work. Client tokens are now scoped to a specific environment and the environment query parameter does not affect the list of toggles that are returned. Older client tokens can only fetch toggles from the default environment.

Admin tokens, on the other hand, are still able to read toggles from all environments. However, you shouldn't really use admin tokens for clients.

Admin tokens vs client tokens

As outlined in the API tokens reference doc, admin tokens are not meant to be used in clients. They have a lot more permissions (that clients don't need) and if they get lost, they could potentially cause a lot more trouble than client tokens.

Because admin tokens need to get toggles from all environments, they support using the environment query parameter to specify which environment they should get toggles from (default is default).

Proxy environments and proxy client environments

Now, regarding the proxy, proxy clients, and the environment property: this stems from the pre-environments versions of Unleash. If you use a client token with the proxy today, it doesn't matter what you put in the environment property at all: it does not affect your toggles.

If you decide to use an admin token, however, you may be able to change the value of the environment field on the fly. Just be aware that this isn't the intended usage, so we can't guarantee that it'll keep working.

The same goes for using admin tokens with other client SDKs.

Another question, then, is: why do you want one proxy (or one client) to be able to access multiple environments? What is it that you're trying to achieve here?

For most clients, they _should _ probably only run in one environment. I can't think of any reasons when you'd want a single instance running in multiple environments off the top of my head, but I'd love to hear about it if you've got a use case where that's useful!

For the proxy, I can see why it might be easier to have a single proxy cover multiple environments. But running multiple environments in one proxy also puts some limitations on how you scale it (at least you can't scale environments independently anymore).

I think you should either remove the environment flag in the client SDKs completely [...] or properly handle environments to align with the server and client sdks.

This is also a good point, and is something I think we should take into consideration, for sure. Again, I'll bring it up with the team and see what they say 😄

from unleash-proxy.

Of course! 😄 That's (partly) why we're here!

Its just that from a developer point of view the documentation and the expected effect was / is misleading.

Yup. I can see this. We are working on updating it though, but there's a lot of documentation to go through, so it takes a bit of time. Do you have any specific bits that were particularly confusing? If you can point them out, I'm sure we could fix them right away 🤓

As you described using an admin key (not on a client sdk directly but for the proxy), it somehow implies that this admin key can be used to allow a single proxy - multi environment use - as you described.

I just want to make sure we're on the same page here: Admin tokens are not intended to be used with the proxy. The proxy is a wrapper service around the Node.js client. It should get a client token. Admin tokens are intended to be used for applications that need to be able to create and delete toggles, projects, users, etc. The official SDKs cannot do that.

Sadly as mentioned it is already not working and i even think this could be a valid use-case if someone would like to use a single proxy for dev/qa (admin token for these two envs) but another proxy for production?

Got it. I didn't know whether it'd work or not, but thought it might be possible to rig it up somehow. I agree wanting to run a single proxy for multiple environments is a valid use case, though.

The good news is that you can actually do that! See this example setup that uses two in-process proxies for the details, but in short it:

• runs two separate proxy processes in one app
• each proxy uses a different client key, so they can access separate environments

At the moment, though, this kind of setup requires you to set it up yourself. We don't offer any ready-made docker images that do this (but there's nothing stopping you from creating one).

I advocate for allowing that the proxy actually can properly handle admin tokens and the environment flag from the client sdk can be used to query the respective environments (allowed via admin token connection specification of the unleash server)

Again: I think this may be a misunderstanding (and undercommunication on our side). The proxy shouldn't handle admin tokens, because it's not an admin tool. The fact that other server-side SDKs let you do that is probably incidental rather than planned.

However, I do think there is a case to be made for multi-environment client tokens (so that a lost token doesn't give the power to delete everything). I'll propose it to the team.

Does that check out? ☺️

from unleash-proxy.

Hi, by design, the proxy will only return enabled feature toggles for a given context.

from unleash-proxy.

Thanks, that is good to know. So that means that passing in context information is not optional. Which differs from the Unleash API, where it is. We might want to make that a little more obvious in the documentation for the proxy.

Still, a call to https://unleash-dev-proxy.innago.com/proxy?environment=development&project=default&appName=Test continues to return an empty array. Is there a minimal set of properties that MUST be included in the context for the proxy to send back some information? If so, what are they? The context page in the docs says that all fields are optional.

In research some more, I'm wondering if the problem is not related to environments. The docs seems to say that with the newest versions of Unleash, which I'm on, environments are tied to environment specific API keys. I'm wondering how that affects proxies? Does it mean that you need a proxy for each environment? Right now I only have one proxy and one API key that is set to type: admin, project: *, environment: *, could that be the problem?

from unleash-proxy.

So yeah, that's what it was. I have created a new key that is type: client, project: default, environment: development and now the proxy works, even if I don't pass in a context. The question remains though, does that mean that I have to deploy a separate proxy for each environment, or is there a way to use the same proxy for both development and production environments?

from unleash-proxy.

does that mean that I have to deploy a separate proxy for each environment, or is there a way to use the same proxy for both development and production environments?

This is possible if you create a custom express app and uses the proxy as a router you mount on separate paths.

Ok, thanks for the info. I guess we can consider this resolved.

from unleash-proxy.

Hey @thomasheartman,

thanks so much for your long and precise answer!
Really appreciate it.

At the moment we opted for different proxies for our different environments hooking them up to a single unleash server and using the client keys as you mentioned. Its just that from a developer point of view the documentation and the expected effect was / is misleading.

As you described using an admin key (not on a client sdk directly but for the proxy), it somehow implies that this admin key can be used to allow a single proxy - multi environment use - as you described.

e.g.
js client sdk (client token) -> proxy (admin token all envs) -> unleash server
whereas the client sdk specifies the environment to retrieve the toggles for.

If you decide to use an admin token, however, you may be able to change the value of the environment field on the fly. Just be aware that this isn't the intended usage, so we can't guarantee that it'll keep working.

Sadly as mentioned it is already not working and i even think this could be a valid use-case if someone would like to use a single proxy for dev/qa (admin token for these two envs) but another proxy for production?

I advocate for allowing that the proxy actually can properly handle admin tokens and the environment flag from the client sdk can be used to query the respective environments (allowed via admin token connection specification of the unleash server)

eg.

js sdk (env : dev or qa ) -> (dev+qa instance) proxy (admin token for dev/qa) -> unleash server
js sdk (env : prod ) -> prod proxy (admin or client token for prod) -> unleash server

lmkwyt.

Best and thanks for your feedback.
Jan

from unleash-proxy.

Hey @thomasheartman,
sorry for my late reply towards this topic! :-) Again really appreciate your POV on this:

Do you have any specific bits that were particularly confusing? If you can point them out, I'm sure we could fix them right away 🤓

Absoluteley:
reference #1

reference #2

#reference 1:
Setting an environment on clients is obsolete as each proxy only can have a single client key which is bound to a single environment anyways - multi env client tokens or the option to add multiple tokens to a proxy would solve this

#reference 2:
this flag is confusing - there is no v9 release so if you not building the proxy from the repo this flag does nothing.

I just want to make sure we're on the same page here: Admin tokens are not intended to be used with the proxy. The proxy is a wrapper service around the Node.js client. It should get a client token. Admin tokens are intended to be used for applications that need to be able to create and delete toggles, projects, users, etc. The official SDKs cannot do that.

We are now thanks for clarifying - I think this should come out a bit better from the documentation or maybe it was just me ;-). Maybe also a reason why I interpreted the admin token to be used for the proxy was two-fold:

1. the proxy does not expose the the token (compared to sdks)
2. the admin token is the only token allowed for multi-environment selection

However, I do think there is a case to be made for multi-environment client tokens (so that a lost token doesn't give the power to delete everything). I'll propose it to the team.

Absolutely checks out looking forward to see this flexibility coming in!

from unleash-proxy.

@janknobloch No worries at all 😄

reference #1
Setting an environment on clients is obsolete as each proxy only can have a single client key which is bound to a single environment anyways - multi env client tokens or the option to add multiple tokens to a proxy would solve this

Aye, I agree this is confusing, but it's technically correct. The text says (emphasis mine):

If set this will be the environment used by the proxy in the Unleash Context. It will not be possible for proxy SDKs to override the environment if set.

And the environment context field is not the same as the environment you specify in a client key. One is just a property of the Unleash context, the other is the new environments feature that Unleash has had since 4.3. This is a holdover from before we introduced environments.

With that taken into consideration: how do you think it would make sense to phrase it to avoid confusion?

reference #2
this flag is confusing - there is no v9 release so if you not building the proxy from the repo this flag does nothing.

Ah, good point. We put that in there last week, I think. v0.9 of the proxy is ready to be released (and was supposed to be earlier last week), but it's just been held up because of some restructuring of the release process. It should go out this week.

Maybe also a reason why I interpreted the admin token to be used for the proxy was two-fold:

1. the proxy does not expose the the token (compared to sdks)

That's fair, but other server-side SDKs also don't expose the tokens. Only front-end clients expose their client keys (which are explicitly not API tokens).

2. the admin token is the only token allowed for multi-environment selection

Aye. As we've discussed, that's intentional, but probably not outlined well enough in the docs. I'm not sure where the best place to add more info on that would be though. Where would you expect to find that information?

from unleash-proxy.