GRPC Core
43.0.0
|
EXPERIMENTAL API - Subject to change. More...
#include <credentials.h>
Data Fields | |
void * | user_data |
int(* | verify )(void *user_data, grpc_tls_custom_verification_check_request *request, grpc_tls_on_custom_verification_check_done_cb callback, void *callback_arg, grpc_status_code *sync_status, char **sync_error_details) |
A function pointer containing the verification logic that will be performed after the TLS handshake is done. More... | |
void(* | cancel )(void *user_data, grpc_tls_custom_verification_check_request *request) |
A function pointer that cleans up the caller-specified resources when the verifier is still running but the whole connection got cancelled. More... | |
void(* | destruct )(void *user_data) |
A function pointer that does some additional destruction work when the verifier is destroyed. More... | |
EXPERIMENTAL API - Subject to change.
A struct containing all the necessary functions a custom external verifier needs to implement to be able to be converted to an internal verifier.
void(* grpc_tls_certificate_verifier_external::cancel) (void *user_data, grpc_tls_custom_verification_check_request *request) |
A function pointer that cleans up the caller-specified resources when the verifier is still running but the whole connection got cancelled.
This could happen when the verifier is doing some async operations, and the whole handshaker object got destroyed because of connection time limit is reached, or any other reasons. In such cases, function implementers might want to be notified, and properly clean up some resources.
user_data: any argument that is passed in the user_data of grpc_tls_certificate_verifier_external during construction time can be retrieved later here. request: request information exposed to the function implementer. It will be the same request object that was passed to verify(), and it tells the cancel() which request to cancel.
void(* grpc_tls_certificate_verifier_external::destruct) (void *user_data) |
A function pointer that does some additional destruction work when the verifier is destroyed.
This is used when the caller wants to associate some objects to the lifetime of external_verifier, and destroy them when external_verifier got destructed. For example, in C++, the class containing user-specified callback functions should not be destroyed before external_verifier, since external_verifier will invoke them while being used. Note that the caller MUST delete the grpc_tls_certificate_verifier_external object itself in this function, otherwise it will cause memory leaks. That also means the user_data has to carries at least a self pointer, for the callers to later delete it in destruct().
user_data: any argument that is passed in the user_data of grpc_tls_certificate_verifier_external during construction time can be retrieved later here.
void* grpc_tls_certificate_verifier_external::user_data |
int(* grpc_tls_certificate_verifier_external::verify) (void *user_data, grpc_tls_custom_verification_check_request *request, grpc_tls_on_custom_verification_check_done_cb callback, void *callback_arg, grpc_status_code *sync_status, char **sync_error_details) |
A function pointer containing the verification logic that will be performed after the TLS handshake is done.
It could be processed synchronously or asynchronously.
user_data: any argument that is passed in the user_data of grpc_tls_certificate_verifier_external during construction time can be retrieved later here. request: request information exposed to the function implementer. callback: the callback that the function implementer needs to invoke, if return a non-zero value. It is usually invoked when the asynchronous verification is done, and serves to bring the control back to gRPC. callback_arg: A pointer to the internal ExternalVerifier instance. This is mainly used as an argument in |callback|, if want to invoke |callback| in async mode. sync_status: indicates if a connection should be allowed. This should only be used if the verification check is done synchronously. sync_error_details: the error generated while verifying a connection. This should only be used if the verification check is done synchronously. the implementation must allocate the error string via gpr_malloc() or gpr_strdup(). return: return 0 if |verify| is expected to be executed asynchronously, otherwise return a non-zero value.