Hi all, my company would like to customize Pinot B...
# generals
Sudeshna Sengupta
05/08/2024, 5:53 PMHi all, my company would like to customize Pinot Broker authentication via extending org.apache.pinot.broker.broker.AccessControlFactory. However, when playing with this idea using a local distribution of the Pinot 1.1.0 code base, I notice that the Broker HTTP server encounters a response 500 (Broker "query/sql" API always leads to HTTP 500 and "Grizzly 2.4.4" error response body) when calling the custom implementation JAR if it's dropped in the local Pinot distribution's "plugins" or "lib" directory, but works beautifully if the concrete, custom implementation of org.apache.pinot.broker.broker.AccessControlFactory is included with a rebuild and redistribution of the local Pinot Broker code base. How does one package and deploy to a Pinot cluster the JAR corresponding to the customization of org.apache.pinot.broker.broker.AccessControlFactory? Is this use case possible, without updating the Pinot Broker code itself? Thanks!
Sudeshna Sengupta
05/13/2024, 11:24 PMI created following Github Pinot issue for this use case: https://github.com/apache/pinot/issues/13148
Sudeshna Sengupta
05/17/2024, 5:44 AMAs I mentioned recently in the issue that I filed, which I also closed: thankfully, we were able to discover the root cause of this issue: since the custom authentication implementation needs to look at the headers stored in the instance of org.apache.pinot.broker.api.HttpRequesterIdentity to obtain the HTTP request's bearer token for validation against Keycloak, any attempt to call org.apache.pinot.broker.api.HttpRequesterIdentity#getHttpHeaders() would fail, because Pinot shades all classes in packages whose names start with "com.google". To work around this, our implementation is using Java reflection to convert the associated collection into a java.util.Map instance, prior to extracting the bearer token.