Interesting... so the Rust AFS server is returning the token in the payload? I believe it should be setting it on the returning headers instead.
In the Java server, you decide on the authentication mechanism. The equivalent of what you're trying to do is `BearerTokenAuthenticator`, which allows you to validate the incoming Basic auth header and set the Bearer token header in the response headers. After a quick look at the JDBC code, it seems like it's looking for the header `authorization=Bearer <token>` in the response to set it for following requests. Maybe the Rust server has a similar auth mechanism to `BearerTokenAuthenticator`? On Thu, Apr 18, 2024 at 9:11 AM Istvan Fodor <i...@istvanfodor.com> wrote: > 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 >> >
