anderseknert commented on issue #5714: URL: https://github.com/apache/apisix/issues/5714#issuecomment-992342340
That's really exciting! Thanks for your work on this @bzp2010 , and everyone else who has been involved 👍 As for best practices, no not really. It's important to note that OPA doesn't do _enforcement_ by design, so IMHO the status code for the client to return upstream should be decided by the client/caller. For an HTTP Gateway this would likely be a 403, but if we leave that decision to the client (i.e. not in the policy response) we can be flexible in reusing the same policy across other clients, where a different type of enforcement (like a 500 response, or just an audit log entry) might be desirable. So for me, I'd say the minimum decision to return would be 1) whether the request is allowed or not, and 2) (optionally) a string explaining the reason if the request was denied. As for reusing the Envoy/Istio authorization input structure, that's an interesting idea, as it would mean you could pretty much take any policy written for those systems and directly use it with APISIX. The downside of that (again, IMHO ;)) is that there's a lot of (most often) unused data being sent with each request. No policy I've seen has used things like the `content-length` of the incoming request. I guess an interesting option could be to allow the input format to be configurable, so that you could either send a minimal request (request method, path, authorization header, etc) or you could configure the plugin to send Envoy/Istio formatted input. That'd provide a good default, while allowing compatibility with those other proxies for those that preferred it. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@apisix.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
