Looking at the docs for their JS SDK, they have this warning:
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
Yes, this! I am dying for need of zerotrust enterprise features and am about to have to actually talk to one of the enterprise sales folks, which will chew up a bunch of time and add stress I’d rather avoid.
More of this please: essential tools for building modern software must be oss; Im fine with paying for a hosted version but just the benefit of learning one tool and being able to use it everywhere (linux, k8s, python etc) is amazing.
It’s pretty useful. We used it at a previous company. We built a custom backend, but used the spec and SDKs.
It took like 2 weeks to build a full custom backend. SDKs across languages worked flawlessly (okay, we did find one bug, reported it, and it was fixed within the day)
Cloudflare are winning these days, they’re just lacking good fine grained permissions. You still have to make an entirely separate account for prod, which messes up SSO since one domain can only be bound to one account.
Their products are cool and I've been happy with them over the years, but their blog right now has had some blunders recently. Also their reliability seems to have been having trouble but does seem better recently.
One account gets compromised and your doomed. A lot of companies even have prod access be a request based system. Most modern security models with zero trust don't let everyone have access to everything, quite the opposite.
Has anyone struggled to run their own feature flagging service? After root causing slow app starts to be caused by the equivalent offering from Firebase, I've been cautious to use any off the shelf solutions
It can get complicated quickly if you're actually using it in a production system. At my prev enterprise saas company we had feature flags that could be turned on per customer / per environment (dev, staging, prod) with permission + logging model such that our support team could also toggle flags with history of who turned on what. We also had "per user" feature flags for certain test users at companies and had DSL rules to evaluate the features
If anyone is interested, you can implement something like that with a few lines of code on the front end. We expose a function that generates a uniformly-distributed hash that you can use for A/B testing and other uses:
Essentially, this can support a huge number of "variants" and within each variant you can have N equal segments. That will help you do A/B testing and flipping features on or off.
> The client provider requires an API token to fetch flag values. This token is not scoped to a single app, so anyone with the token can evaluate flags across all apps in your account. Use the client provider with caution in public-facing applications.
https://developers.cloudflare.com/flagship/sdk/client-provid...
Can anyone clarify... why the client SDK, designed to be deployed to browsers, requires caution? Does this mean that any client could send requests with a new targetingKey and observe other users' flags?
While flags probably shouldn't be critical information, this seems like an interesting design choice.
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
https://blog.cloudflare.com/enterprise-grade-features-for-al...
—-
I don’t believe a single enterprise only feature has made its way to lower tier (paid) account yet.
I’m most interested in:
https://developers.cloudflare.com/speed/optimization/content...
It took like 2 weeks to build a full custom backend. SDKs across languages worked flawlessly (okay, we did find one bug, reported it, and it was fixed within the day)
[1] https://vercel.com/docs/flags/vercel-flags
And on the back end, you'd use it like this:
https://github.com/Qbix/Platform/blob/main/platform/classes/...
Essentially, this can support a huge number of "variants" and within each variant you can have N equal segments. That will help you do A/B testing and flipping features on or off.