Fix Evaluate logic

[iskey]

related to eclipse-xpanse/xpanse#896
related to eclipse-xpanse/xpanse#900

Remove the isAllow from the request and response.

As the opa will try to evaluate all the variables into the bindings, we just need to care about the allow and the deny variables in the rego. If no such variables, this rego will be ignored.

$ opa eval --data policy.rego --input input.json "result=data.example.auth"
{
  "result": [
    {
      "expressions": [
        {
          "value": true,
          "text": "result=data.example.auth",
          "location": {
            "row": 1,
            "col": 1
          }
        }
      ],
      "bindings": {
        "result": {
          "allow": true,
          "deny": true,
          "x": 1,
          "y": "hello world"
        }
      }
    }
  ]
}

[swaroopar]

would it make sense to move all structs to a different package?

[iskey]

Actually, If no complex business logic, putting the structs where they have been used is also a good idea.

[swaroopar]

was only thinking to keep all data models in once place. This will help us in future to easy check the correct places instead of searching.

[swaroopar]

its better to define a struct for the return type as well.

[swaroopar]

is it possible to make policy-man more generic.. that it simply executes and returns results of all rules. And only in xpanse, we can build a limitation that the rego rules must contain allow/deny rules?

[iskey]

If we do it like this, then the response of this API will not be a stable structure. and the Xpanse must deserialize the response and check the allow/deny rules itself.

[swaroopar]

ok. Then we can provide two services. one with specific allow and deny.. and one with a generic one.

[swaroopar]

do we need to append this? What I thought is, since we are loading the string fully, the rego must contain the package name already.

[iskey]

If we let the users define the package name by themselves, we will not be able to be aware of which package to evaluate, or we must extract the package name from the rego files,

actually, this is an one-off policy here, the package name here is useless.

[swaroopar]

@iskey should we only then control if the package name already exists and overwrite it?

[swaroopar]

LGTM