Hi Jordan,
I was testing with the example code in the Apache Arrow Rust repo:
https://github.com/apache/arrow-rs/blob/master/arrow-flight/examples/flight_sql_server.rs


To the best of my knowledge, it returns a token in the payload. I can see
in ngrep that do_handshake is called and this is what it returns:

let result = HandshakeResponse {
            protocol_version: 0,
            payload: FAKE_TOKEN.into(),
        };
let result = Ok(result);
let output = futures::stream::iter(vec![result]);
return Ok(Response::new(Box::pin(output)));

In the Java code it looks like the authorization header is not part of the
metadata that is passed:

No authorization header! metadata = MetadataMap { headers: {"content-type":
"application/grpc", "te": "trailers", "user-agent":
"grpc-java-netty/1.60.0", "username": "admin", "grpc-accept-encoding":
"gzip"} }

I logged the metadata on the Rust side and the authorization header was
missing indeed.

IN the Netty logs it looks like the right Basic auth is passed in on
getConnection, and the token comes back fine:

10:50:53.890 [grpc-nio-worker-ELG-1-2] DEBUG
cfjd.io.grpc.netty.NettyClientHandler -- [id: 0x53dab587, L:/127.0.0.1:59757
- R:/127.0.0.1:50050] OUTBOUND HEADERS: streamId=3
headers=GrpcHttp2OutboundHeaders[:authority: 0.0.0.0:50050, :path:
/arrow.flight.protocol.FlightService/Handshake, :method: POST, :scheme:
http, content-type: application/grpc, te: trailers, user-agent:
grpc-java-netty/1.60.0, username: admin, grpc-accept-encoding: gzip,
authorization: Basic YWRtaW46cGFzc3dvcmQ=] streamDependency=0 weight=16
exclusive=false padding=0 endStream=false
10:50:53.895 [grpc-nio-worker-ELG-1-2] DEBUG
cfjd.io.grpc.netty.NettyClientHandler -- [id: 0x53dab587, L:/127.0.0.1:59757
- R:/127.0.0.1:50050] OUTBOUND DATA: streamId=3 padding=0 endStream=true
length=5 bytes=0000000000
10:50:53.898 [grpc-nio-worker-ELG-1-2] DEBUG
cfjd.io.grpc.netty.NettyClientHandler -- [id: 0x53dab587, L:/127.0.0.1:59757
- R:/127.0.0.1:50050] INBOUND HEADERS: streamId=3
headers=GrpcHttp2ResponseHeaders[:status: 200, content-type:
application/grpc, date: Thu, 18 Apr 2024 15:50:53 GMT] padding=0
endStream=false
10:50:53.899 [grpc-nio-worker-ELG-1-2] DEBUG
cfjd.io.grpc.netty.NettyClientHandler -- [id: 0x53dab587, L:/127.0.0.1:59757
- R:/127.0.0.1:50050] INBOUND DATA: streamId=3 padding=0 endStream=false
length=17 bytes=000000000c120a757569645f746f6b656e

Subsequent calls in the JDBC/Netty log don't show the authorization header.


On Wed, Apr 17, 2024 at 2:16 PM Istvan Fodor <i...@istvanfodor.com> wrote:

> Hi All,
>
> I am trying to write a basic example of a Java/JDBC code querying from the
> Arrow Rust example implementation of the Arrow Flight SQL server (
> https://github.com/apache/arrow-rs/blob/master/arrow-flight/examples/flight_sql_server.rs).
> My impression was that based on the interoperability goals of the Arrow
> project, these should work together just fine.
>
> It turns out the in my Java code, I can authenticate (getConnection())
> fine against the Rust server. User/password goes in, and a token comes
> back, but subsequent calls (executeQuery() for example) don't include the
> authorization token at all (it should look like authorization=Bearer
> <token>), whereas I expected the token to just propagate to subsequent
> calls as it should.
>
> I am using the 15.0.2 flight-sql-jdbc-driver. Any ideas what my issue
> could be? Is there any extra setup that we need to do to get JDBC + Basic
> auth to work besides supplying user and password parameters?
>
> Thanks,
> Istvan Fodor
>

Reply via email to