bugs/not-equals-in-loop #130
Conversation
anderseknert
force-pushed
the
not-equals-in-loop
branch
from
5382c15
to
6152d5b
Compare
|
|
||
| some i | ||
| neq_term.value[i].type == "var" | ||
| startswith(neq_term.value[i].value, "$") |
There was a problem hiding this comment.
We could have a "constants" package and put the "wildcardprefix" in it. 🤔
There was a problem hiding this comment.
Hmm yeah, that would read better. We're doing a lot of these checks in the very hot path of find_vars and such, so I wonder if there'd be any difference in performance using a string literal versus a data reference? 🤔 I guess I'd have to measure. Making a note on that.
| deny if { | ||
| "admin" != input.user.roles[_] | ||
| } |
There was a problem hiding this comment.
It would also work for this, right?
| deny if { | |
| "admin" != input.user.roles[_] | |
| } | |
| deny if "admin" != input.user.roles[_] |
There was a problem hiding this comment.
Yes! I've added a test case for good measure. I think I'll keep the longer version in the docs though as it makes it clearer that the condition is in the rule body. But maybe it's just my old habits.
|
|
||
| ```rego | ||
| package policy | ||
|
|
There was a problem hiding this comment.
For consistency, should we use if here?
anderseknert
force-pushed
the
not-equals-in-loop
branch
from
6152d5b
to
ab1700d
Compare
Like a few other rules, this won't catch all violations as we don't yet traverse nested structures like comprehensions or `every` constructs. Fixes #79 Signed-off-by: Anders Eknert <anders@styra.com>
anderseknert
force-pushed
the
not-equals-in-loop
branch
from
ab1700d
to
4b36032
Compare
Like a few other rules, this won't catch all violations as we don't yet traverse nested structures like comprehensions or
everyconstructs.Fixes #79