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.
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.
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.
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.
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.
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.
Let's think about it. This is probably something used internally at CloudFlare and someone thought I'd be interesting to make it public.
There is no way 6 months ago someone at CloudFlare thought it was a good idea to build a competitor to say LaunchDarkly.
Care to share why
This is nice, but I’m still waiting for this to be delivered (which ironically is probably using Flagship):
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...
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.
Cloudflare oss?
OpenFeature was new to me, neat! Anyone have experience integrating this? https://openfeature.dev
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.
Yes! I just opened a support case today asking for more fine grained permissions.
After years of AWS I gave Cloudflare a whirl and loved the UX but ultimately retreated back due to the same concern. They are so close though..
Just let everyone have access to prod?
Poor access and change management governance.
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.
hooboy that was a good one!
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.
This is exactly what stops me from using them for real work. I love their free tier for my hobby stuff.
Will never use them without prepayment or spending limit options
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's literally a field in your database. I could never fathom why this needs to be an outsourced service never mind an entire company.
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
Worth noticing a Vercel equivalent: https://github.com/vercel/flags
That is actually their SDK / provider agnostic library. The better parallel to this new Cloudflare offering is Vercel Flags[1] (confusing I know)
[1] https://vercel.com/docs/flags/vercel-flags
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:
https://github.com/Qbix/Q.js/blob/main/src/js/Q.minimal.js#L...
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.