Conversation
✅ Deploy Preview for polite-licorice-3db33c ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
Signed-off-by: Todd Baert <todd.baert@dynatrace.com>
89a7f50 to
ebde807
Compare
|
|
||
| - **Language agnostic**: Rules must be portable across different programming languages, ideally relying on existing expression language(s) | ||
| - **Safe evaluation**: No arbitrary code execution or system access | ||
| - **Deterministic**: Same inputs must always produce same outputs |
There was a problem hiding this comment.
$flagd.timestamp seems to break this requirement?
There was a problem hiding this comment.
I guess it depends on whether or not you consider the timestamp an sort of implicit input... We could change it to "predictable" though.
There was a problem hiding this comment.
To me, what users provide through the evaluation API are the input, and timestamp is not there.
There was a problem hiding this comment.
OK I'll change that to "predictable".
There was a problem hiding this comment.
Actually I think I'll keep Deterministic (because I believe it still is), but mention the timestamp exception situation.
| #### Benefits realized | ||
|
|
||
| - Rules can be stored in databases, transmitted over networks, shared between frontend/backend, and embedded in Kubernetes custom resources | ||
| - No eval() or code injection risks - computations are deterministic and sand-boxed |
There was a problem hiding this comment.
I think this depends on the implementation of the eval engine, and less about the language itself.
For example, a JavaScript JSON logic engine had a CVE that allows command injection: https://nvd.nist.gov/vuln/detail/CVE-2021-4329
There was a problem hiding this comment.
Ya, that's fair. At least at the time, we saw JSONLogic as less likely to have these sort of issues.
|
|
||
| flagd's targeting system was designed with several key requirements: | ||
|
|
||
| ## Requirements |
There was a problem hiding this comment.
What was the requirement for the typing system back then? Is weakly typed a requirement or a result?
| ## Considered Options | ||
|
|
||
| - **Custom DSL**: Would require parsers in every language | ||
| - **JavaScript/Lua evaluation**: Security risks and language lock-in |
There was a problem hiding this comment.
What was the biggest concern for Lua?
Lua engine normally comes with a sandboxed VM, which is more lightweight and secure IMO.
There was a problem hiding this comment.
Lua was something I briefly advocated for, I've had some experience with it doing nginx customization. I remember a community member being opposed to it on the basis of security concerns, and at the time it seemed like a higher bar.
|
|
||
| ### Positive | ||
|
|
||
| - Good, because implementations exist across languages |
There was a problem hiding this comment.
True, but also there's not much consistency guarantee across languages.
There was a problem hiding this comment.
Well, there's enough at least that our test suite works in Go, Python, Java, JS, and .NET. It covers every operation and a fair few edge cases: https://github.com/open-feature/flagd-testbed/tree/main/gherkin
I acknowledge there's inconsistencies, particularly around undefineds. It's one of the reasons the JSONLogic org exists (though admittedly it's been hard to make progress with the few volunteers there). I'm sure we could use your help if you're interested in contributing to that.
There was a problem hiding this comment.
My first alternative in this comment might be a reasonable solution to some implementation inconsistencies. Interested in your take on that; we could do it progressively and it would be non-breaking.
|
|
||
| flagd's targeting system was designed with several key requirements: | ||
|
|
||
| ## Requirements |
There was a problem hiding this comment.
Mostly due to the JS typing system, JSONLogic's behavior on undefined values (context not provided, for example) can be very confusing. Was this considered and evaluated?
There was a problem hiding this comment.
I can't recall if that particular behavior was discussed.
|
@tangenti Thanks for the feedback. I'd like to make it clear that personally, though I think our current JSONLogic implementation(s) are "good enough", I think there's ways to improve, and alternatives. To name a few:
I would be open to any of the above, and lend my support, if there's engineering effort to spare for these. |
|
Since this is historical, I'm merging this. That doesn't mean it can't be edited or superseded, it's simply an explanation of a previous decision and reflects the current implementation. |
Another "retrospective" ADR, like the cucumber one.
This explains our JSONLogic choice, shared
$evaluators, as well as the the semantics of flagd's use of OpenFeature's resolution reasons.