I ended up finding a solution BTW. I’m (ab)using the stats.Handler interface. TagConn is invoked each time a connection is created, so I can stick my session cache in the context (and the cool thing is that each Stream’s context is derived form the context returned by TagConn). Then in HandleConn, when the event is ConnEnd, I can handle the connection going down.
On Mon, May 22, 2017 at 1:32 PM, 'Eric Anderson' via grpc.io <[email protected]> wrote: > On Fri, May 19, 2017 at 3:22 PM, Benoit Sigoure <[email protected]> wrote: >> >> In Foo(), I authenticate the client using a user/password passed as >> metadata before executing the FooRequest. Authenticating the client >> each time is expensive, so I want to remember somewhere that I already >> authenticated this client (for this discussion let’s ignore security >> considerations like caching policy etc). > > > I'd suggest caching the authentication result and check the cache each > request. The client is not aware when a new connection is used and binding > the authentication to the connection breaks some proxying models. It’s fine that the client is unaware or that proxy would mess things up in between. The client is always sending their credentials with each all as metadata, so in the worst case I have to re-authenticate the client from scratch if there was a transport-level problem (be it a connection issue or a proxy in between not keeping the connection open). >> I can’t return a session ID >> or something like that to the client, I just receive the user/pass >> each time. > > > Well, you can, but gRPC won't help the client to pass that value in the > future. It would generally be discouraged. What I meant by “I can’t” is that the client always just sends its credentials, period. I can’t return a cookie-like value to the client and hope it would send it back with subsequent requests, because I’m not writing the code of the client and I can’t assume that the client will send anything other than just their credentials. >> My thinking was to cache this information somewhere in the transport, >> but there’s a small twist: I need to clean up something whenever the >> transport goes down. I can’t tie this to the Stream because this is >> not a streaming RPC so each call to Foo() has its own single-use >> stream in the context. I can get access to the transport >> (*transport.http2Server), but I can’t access its private shutdownChan >> to wait for the transport to be closed. >> >> So what’s the best way (if any) to tie something to the lifetime to >> the transport? > > > What sort of thing do you need to clean up? Like removing an ID from a map? Something like that… Does it matter what I need to do? I need to releases some resources I allocate during authentication, the details don’t really matter IMO, just some cleanup that needs to happen. -- Benoit "tsuna" Sigoure -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/grpc-io. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/CAFKYj4dKUpBo2yxU6hWAAadMXR%3Dctk--e99jEWTFTTiUPVzqQQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
