On grpc response flow #81
Conversation
didierofrivia
force-pushed
the
external-auth
branch
from
17cc2f0
to
722f149
Compare
didierofrivia
force-pushed
the
on_grpc_response_flow
branch
3 times, most recently
from
626b680
to
c9e8f51
Compare
didierofrivia
force-pushed
the
on_grpc_response_flow
branch
2 times, most recently
from
0712164
to
9deb28e
Compare
didierofrivia
force-pushed
the
external-auth
branch
from
722f149
to
dacfcdc
Compare
didierofrivia
force-pushed
the
on_grpc_response_flow
branch
2 times, most recently
from
6619cfe
to
194f62c
Compare
didierofrivia
force-pushed
the
external-auth
branch
2 times, most recently
from
37b6f1d
to
312710e
Compare
didierofrivia
force-pushed
the
on_grpc_response_flow
branch
from
194f62c
to
f47cfa8
Compare
didierofrivia
force-pushed
the
on_grpc_response_flow
branch
3 times, most recently
from
f000154
to
5a4bc29
Compare
Signed-off-by: dd di cesare <didi@posteo.net>
* Could get confusing with proxy_wasm `Actions` * Also with plugin configuration `Action` Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
* Services also building the response Message Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
* When Operation `n` is Done, it's removed and it triggers Op n+1 Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
Signed-off-by: dd di cesare <didi@posteo.net>
didierofrivia
force-pushed
the
on_grpc_response_flow
branch
from
5a4bc29
to
4272ff7
Compare
There was a problem hiding this comment.
Couldn't spot anything explicitly broken... So I'm in favor in merging. I'd then slightly focus on merging this all to main & worst case nightly catches something, and we have plenty of time to then fix it (while making our test coverage better :)
That would require looking into the config bits on the kuadrant operator end tho
| @@ -37,7 +37,7 @@ pub use { | |||
| AttributeContext_Request, | |||
| }, | |||
| base::Metadata, | |||
| external_auth::CheckRequest, | |||
| external_auth::{CheckRequest, DeniedHttpResponse, OkHttpResponse}, | |||
There was a problem hiding this comment.
I see this is more than RL then... which is fine ;)
| } | ||
| } else { | ||
| warn!("No Operation found with token_id: {token_id}"); | ||
| self.handle_error_on_grpc_response(&FailureMode::Deny); // TODO(didierofrivia): Decide on what's the default failure mode |
There was a problem hiding this comment.
Yeah, interesting... I think this could (not asking to change the current behavior really) be a .next().expect("State machine is broken, we expected an operation to handle the gRPC response"), which if I'm not mistaken result in a 500.
| let res = match GrpcMessageResponse::new( | ||
| operation.get_extension_type(), | ||
| &res_body_bytes, | ||
| status_code, | ||
| ) { | ||
| Ok(res) => res, | ||
| Err(e) => { | ||
| warn!( | ||
| "failed to parse grpc response body into GrpcMessageResponse message: {e}" | ||
| ); | ||
| self.handle_error_on_grpc_response(failure_mode); | ||
| return; | ||
| } | ||
| }; | ||
| match operation.get_extension_type() { | ||
| ExtensionType::Auth => {} // TODO(didierofrivia): Process auth grpc response. | ||
| ExtensionType::RateLimit => self.process_ratelimit_grpc_response(res, failure_mode), | ||
| } |
There was a problem hiding this comment.
I think much of that logic could be encapsulated in the operation itself... Probably would need a bigger refactoring tho (e.g. an enum for how to transition, i.e. () or GrpcMessageResponse, to the next state)... Same with the code in process_ratelimit_grpc_response... its back & forth between these two layers that I don't think adds value, nor is required...
Signed-off-by: dd di cesare <didi@posteo.net>
Part of the work needed for #58
This PR is yet another step closer to the new way the WASM Shim will be handling multiple operations of External Rate Limit and Auth.
It introduces the
GrpcMessageResponsethat will be responsible of parsing the response back from the external services into the correct type, thus allowing the Filter to decide on the flow given the different actions defined in configuration.So far, it only replicates the previous Rate Limiting flow, opening the door to implement the Auth one.
Next step: Implement the actual Auth flow within the Filter.
Notes: