Implement GRPC response handler in Decisions API about oathkeeper HOT 15 CLOSED

Incorrect stalebot detection - this was assigned a milestone.

from oathkeeper.

Would it be possible to give more context on this? I've never used grpc myself, so I lack some background. Is grpc running over HTTP(s)? Are the same headers used and do they represent the same things? If grpc runs as a (binary) format over HTTP, why do we even care here? We're not transforming/modifying the payload, right?

from oathkeeper.

Yes gRPC runs over HTTP/2. The headers are more or less the same as in HTTP/1 /w Authorization headers etc (read more here https://apievangelist.com/2018/02/05/headers-used-for-grpc-over-http2/). But gRPC have some addtitional headers as well. gRPC client except "binary" payload back, whenever a json payload is returned it will not be recognized but the grpc client, like a auth failure from oathkeeper.

Empty body response would be fine but with the grpc-status and grpc-message header with the error.

But your are totally right whenever the request is granted by oathkeeper everything works as excepted.
This fix would make the gRPC client act accordingly if we get a auth failure for instance.

some more info here:
https://www.d3void.net/post/grpc-with-http/

from oathkeeper.

Ok, I think this requires a bit more thinking around gRPC in general:

1. Do we provide gRPC APIs alongside REST ones?
2. How do we document, generate, and publish gRPC APIs?
3. What security mechanisms of gRPC (if any) can we use or enhance?

I think this will be a longer discussion, but it will be a good one!

from oathkeeper.

A quick fix which works sufficient is to do something like this:

from previously getting this reponse:
rpc error: code = Internal desc = transport: received the unexpected content-type "application/json"
and now getting:
rpc error: code = Unauthenticated desc = Unauthorized

from oathkeeper.

probably would be enough to implement the content type in https://github.com/ory/herodot

this workaround is ok for me now.

from oathkeeper.

Yeah, I think it makes sense to have the workaround in oathkeeper directly. We'll need a bit more work on herodot to support grpc properly. Feel free to PR!

from oathkeeper.

Looks like this issue still prevails. Any workaround in 2020?

from oathkeeper.

PRs and contributions are always welcome, so if you want to give this a shot @rverma-jm

from oathkeeper.

@lsjostro Are you please able to indicate where you would add this work around currently within the current release?

Would it be here:

https://github.com/ory/oathkeeper/blob/master/api/decision.go#L86

And would you completely replace the current function?

Thanks.

from oathkeeper.

We are also interested in this feature.

Is there any progress on this? If not, is there anything we still need to discuss before changes can be made?

I could look into this and try to contribute this feature, if there are no blockers.

from oathkeeper.

from oathkeeper.

I am marking this issue as stale as it has not received any engagement from the community or maintainers in over half a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• open a new issue with updated details and a plan on resolving the issue.

We are cleaning up issues every now and then, primarily to keep the 4000+ issues in our backlog in check and to prevent maintainer burnout. Burnout in open source maintainership is a widespread and serious issue. It can lead to severe personal and health issues as well as enabling catastrophic attack vectors.

Thank you for your understanding and to anyone who participated in the issue! 🙏✌️

If you feel strongly about this issues and have ideas on resolving it, please comment. Otherwise it will be closed in 30 days!

from oathkeeper.

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan on resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneous you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

from oathkeeper.

This is still an issue in 2024

from oathkeeper.