scim2 / filter-parser Goto Github PK

The filtering spec has this section: subAttr = "." ATTRNAME; a sub-attribute of a complex attribute. I determined I need to support a basic form of a PATCH endpoint and this is one scenario I was going to attempt to support in your wonderful SCIM library. Quick example:

parser := scim.NewParser(strings.NewReader("members[value eq \"whatever\"].displayName"))
filter, _ := parser.Parse() 

// filter ends up being:
AttributeExpression{
    AttributePath: "members.value",
    CompareOperator: "equal",
    CompareValue: "whatever",
}

Are you open to me adding a SubAttribute field to the AttributeExpression struct? Before doing any work I wanted your input, thanks in advance!

These filters cant be parsed
userType._id eq "Employee" parse: expected op.Or [0x1113820 0x1110500 0x11119c0 0x1111ca0] but got "u"
_userType eq "Employee" parse: expected op.Or [0x1113820 0x1110500 0x11119c0 0x1111ca0] but got "_"

From the RFC I understand it as it should be allowed:

     ATTRNAME  = ALPHA *(nameChar)

     nameChar  = "-" / "_" / DIGIT / ALPHA

I'm not sure how to traverse a parsed expression with version 2.1.1. For version 1.0.0 we could recurse through the Expression by

func walkExpression(e fp.Expression) error {
    switch stmt := e.(type) {
	case fp.UnaryExpression: 
		ex, err := walkExpression(stmt.X)
	case fp.BinaryExpression:
		ex, err := walkExpression(stmt.X)
		ey, err := walkExpression(stmt.Y)
	case fp.AttributeExpression:
		// verify/use the attribute
	case nil:
	default:
	}
}

Im not sure how to perform a similar operation with v2.1.1,
A similar technique with 2.1.1 gives me an error

	switch stmt := (e).(type) {
	case fp.LogicalExpression: <-

impossible type switch case: e (type filter.Expression) cannot have dynamic type filter.LogicalExpression (filter.exprNode method has pointer receiver)

Is there a recommended way to traverse the expression?

And thanks for the release earlier!

If query is having filter like
filter=meta.resource_type eq "test" - fails

or

filter=meta co "W/"990-6468886345120203448"" - fails

filter with two inverted commas or underscore, it fails to parse.

In the https://tools.ietf.org/html/rfc7644#section-3.4.2.2
there is an example of the eq operator having the alternate casing Eq giving the same results.

Attribute names and attribute operators used in filters are case
   insensitive.  For example, the following two expressions will
   evaluate to the same logical value

   filter=userName Eq "john"
   filter=Username eq "john"

When I try this out I get the error
could not parse query: parse: expected op.Or [0x1c74b80 0x1c6ef20 0x1c71740 0x1c71d20] but got "u"

I can only set enumeration for CompareOperator for conversion now
What are some good idea?

Precedence (brackets) seem to be ignored when parsing a filter like (ignore the non scim attributes):
expression := "( username eq \"test\" or request.path sw \"/finance\" ) and subject eq \"abc\""

Calling filter.ParseFilter([]byte(expression)) returns a filter.Expression result whose string value is:
username eq "test" or request.path sw "/finance" and subject eq "abc"

I have tried having spaces between brackets ("(") and content as well as no spaces.

I notice that the test does not actually validate the result, it just tests for no detected errors.

We should (also) support returning json.Number instead of an int or float64, to prevent losing precision.

The filter expression
name pr and not (first eq "test") and not (another eq "test")

parses into an expression with an really deep (inifinite?) LogicalExpression.Left chain.

and results in a stack overflow if printed

=== RUN   Test_Parsing/crashes?
runtime: goroutine stack exceeds 1000000000-byte limit
runtime: sp=0xc0201e0578 stack=[0xc0201e0000, 0xc0401e0000]
fatal error: stack overflow