Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

In and not-in operators for JSON pattern-matching #357

Open
guicassolato opened this issue Oct 27, 2022 · 5 comments
Open

In and not-in operators for JSON pattern-matching #357

guicassolato opened this issue Oct 27, 2022 · 5 comments

Comments

@guicassolato
Copy link
Collaborator

It would be nice to have in and not-in operators amongst the ones supported by Authorino's JSON pattern-matching, so values fetched from the Authorization JSON can be checked if included/not included in a particular static list, without requiring an OPA policy for that.

This is more or less the opposite of the incl and excl operations, which check if a list fetched from the Authorization JSON includes/does not include a particular static value.

@Rohith-Raju
Copy link
Contributor

Hey @guicassolato, I'd like to work on this 😄

@Rohith-Raju
Copy link
Contributor

Rohith-Raju commented Apr 8, 2023

Hey @guicassolato, I thought about this and here's what I came up with.

  1. Add a new field in StaticList []string in JSONPatternMatchingRule.
type JSONPatternMatchingRule struct {
	Selector string
	Operator string
	Value    string
	StaticList []string
}
  1. Add a new switch case operatorIn to check if values fetched from the Authorization JSON contain elements in the StaticList. Opposite can be done to out.
case operatorIn:
		exists := make(map[string]bool)
		for _, value := range expectedList {
			exists[value] = true
		}
		for _, value := range obtainedValue.Array() {
			if !exists[value.String()] {
				return false, nil
			}
		}
		return true, nil

WDYT?

@guicassolato
Copy link
Collaborator Author

@Rohith-Raju,

We can add StaticList []string to JSONPatternMatchingRule but 2 things come to mind:

  1. We still need to expose this option at the level of the API, i.e.

    Value string `json:"value,omitempty"`

    At the API, instead of introducing a new field, I thought about changing the type of Value to runtime.RawExtension. Depending on the operator, the value could be unmarshalled as string into JSONPatternMatchingRule.Value or as []string into JSONPatternMatchingRule.StaticList.

  2. Why just string and []string, I wonder. Should we change the type of JSONPatternMatchingRule.Value to any and open for other JSON types as well?


For the implementation (ignoring (2) above, thus thinking only string and []string), I think obtainedValue would be a simple string, while expectedValue would be the slice. I.e.

case operatorIn:
	for _, expectedValue := range rule.StaticList {
		if expectedValue == obtainedValue.String() {
			return true, nil
		}
	}
	return false, nil 
}

@guicassolato
Copy link
Collaborator Author

@alexsnaps, I guess we can close this in favour of #475. WDYT?

@alexsnaps
Copy link
Member

👍

@guicassolato guicassolato modified the milestones: v0.18.x, v0.19.x Aug 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Status: No status
Development

No branches or pull requests

3 participants