degree9 / covenant Goto Github PK

Covenant does not currently support the UUID type

currently, especially when working with JWT, it makes sense to put strings in the role data being validated, like:

{:roles #{"admin" "editor"}}

OTOH, specs usually look like fully qualified keywords, like this:

{:roles #{:foo.bar/admin :foo.bar/editor}}

For RBAC checking it might make sense to compare on role name only, but then also maybe that doesn't make sense because it wouldn't allow two different editor roles from different systems on the same JWT...

currently the tests introduced in #5 use sets of handrolled examples rather than generated values.

i'm not sure if generative tests are just circular logic though... because of course the values generated by the spec will pass the spec... that might not actually tell us anything >.<

Hi,

I am planning to implement an attribute-based access control system for a web service at work. I was exploring options in Clojure and came across your repository. Has there been any progress on this? Do you need help? Please share any design thoughts or plans that you have.

sweep cljs files to be cljc

Covenant does not currently support the regex type

js/NaN is a PITA for the tests in #5 because:

(clojure.set/difference #{js/NaN} #{js/NaN}) ; #{js/NaN}

So the valid/invalid filter does not work at all.

currently covenant.core only does strict/strong checking, would be nice to have a flag for this.

In #5 we show that v can validate itself as a covenant, and that vanilla specs can validate v.

We have not shown that v can validate the other values that are valid.

The first attempt at this ran up against the issue that of course if we allow the valid values in :covenant.core/any to be used as a covenant for each other, then we always return true for every value, which is pretty useless...

Currently the errors produced by covenant are faulty. The only valid data from an error is which input data fails the spec. The spec which failed should be replaced with the interpreted data structure as the spec itself is an internal component. We should also be able to use the data + interpreted spec to generate human readable errors without going through the lengths that https://github.com/alexanderkiel/phrase does.

The current implementation only checks that the data is a function.

Options:

1. function
2. function and equal