Has anyone devised a good way to add a dynamic aut...

# apollo-kotlin

[clark]

Has anyone devised a good way to add a dynamic auth header to a multiplatform apollo client?

Seems like the recommended OkHttp interceptor would only work on Android, right?

[mbonnin]

Yup, all the docs are for the JVM runtime.

[mbonnin]

You could handle this in platform specific code and use an OkHttp interceptor for the JVM though as this is battle-tested

[mbonnin]

And on iOS, the NetworkTransport takes a DataTaskFactory so maybe you could inject the header there?

[mbonnin]

The only thing to be aware of is I think the DataTaskFactory gets called on the main thread

[clark]

Thanks for the context! I think I'll just wrap my apollo client in a provider that is aware of the auth token and creates a new one when it is changed

[rocketraman]

Use an ApolloRequestInterceptor. The constructor of ApolloClient has an interceptors parameter that takes a list of these. I use it in common code to add bearer tokens to my requests. There is a built-in one called BearerTokenInterceptor that you can use as an example.

[rocketraman]

@mbonnin You were the one to originally point this out to me!

[rocketraman]

https://spectrum.chat/apollo/apollo-android/android-multiplatform-interceptor-to-set-request-header~40daa798-1271-48cb-a260-2fa8d4483273

[mbonnin]

Yup, that works too! Thanks for the reminder!

[mbonnin]

I actually wrote this BearerTokenInterceptor 🙈

[rocketraman]

Lol, funny how we sometimes forget our own work.

[rocketraman]

I had to customize it for my situation to deal with token expiry. Its been working really well on both Android and iOS.

[mbonnin]

How do you handle the token refresh ? With ktor or do you wrote custom iOS/Android HTTP code?

[rocketraman]

I use Firebase Auth, which I'm accessing via GitLive's Firebase MPP library (https://github.com/GitLiveApp/firebase-kotlin-sdk). All my integration code is thus in commonMain!

[mbonnin]

Ooooho that's nice ✨

[rocketraman]

It is quite lovely 🙂

[mbonnin]

I might have broken something 🙈 . -dev releases change quite fast these days...

[Paul Davies]

I've had the debugger and some logs in, and the Interceptor methods are being called to retrieve the token from what I can see.

But they don't actually end up in the request so I get a 401

[mbonnin]

Next -dev will have a HttpRequestInterceptor that should make adding a header easier: https://github.com/apollographql/apollo-android/pull/3151

[Paul Davies]

Worth noting I was on Kotlin 1.4.2 (mt coroutines), so I bumped to 1.5.0 and 1.5.10 which made no difference either

[mbonnin]

I'm guessing this above PR is maybe what broke the headers stuff

[Paul Davies]

Maybe I can roll back a few versions and see.
Does that client building code look okay?

[mbonnin]

Looks good to me!

[mbonnin]

For next version, I'm looking at something like:

return ApolloClient(
            networkTransport = ApolloHttpNetworkTransport(
                serverUrl = "<https://core-gql-sohj3qqawq-ew.a.run.app/graphql>",
                headers = mapOf(
                    "Accept" to "application/json",
                    "Content-Type" to "application/json"
                ),              
            ).withHttpInterceptor(BearerTokenInterceptor(tokenProvider)
        )
            .withCustomScalarAdapter(DateTimeAdapter.graphQlName, DateTimeAdapter())
            .withCustomScalarAdapter(DateAdapter.graphQlName, DateAdapter())
            .withStore(apolloStore)

[mbonnin]

I think it makes sense for the Authorization header to be part of a HttpInterceptor, like with OkHttp, and not at the GraphQLInterceptor level

[Paul Davies]

Yeah I agree, that would be nice!

[rocketraman]

Yes, agreed. There was a lot of extra rigamarole in the interceptor to extract and modify the the http execution context from the ApolloRequest, and pass through the rest of it. Being able to work directly at the HTTP level will definitely simplify the logic.

[Paul Davies]

@mbonnin need me to open an issue for this? or just wait for the next dev release?

[mbonnin]

It'll be in the next dev release

[mbonnin]

Might even be -alpha actually 🤞

[Paul Davies]

Don't get me excited 😃

[mbonnin]

Looks like @audriusk had the exact same issue 2 min ago : https://github.com/apollographql/apollo-android/issues/3160

[Paul Davies]

If it helps I've gone back to dev9 and it doesn't work there either.

[Paul Davies]

FWIW, I love that the interface of the BearerTokenInterceptor takes care of the concurrency by expecting a suspend fun.

I had so much trouble trying to use the Firebase library mentioned above until I found BearerTokenInterceptor

[mbonnin]

Looking into the BearerTokenInterceptor thing right now. Maybe we can do a -dev12 quickly.

[Paul Davies]

Happy to try it out and report back if you do!!

I'm having a tech debt week, so I've got time (dunno if thats a good thing or a bad thing 😆 )

[mbonnin]

Sorry that took a while because we had a custom hook into the HTTP pipeline for Kotlin native that I had to refactor. PR is there: https://github.com/apollographql/apollo-android/pull/3161. I'll merge it once tests pass so that it's in the snapshots and make a version tomorrow

[Paul Davies]

Really appreciate you pulling it together so quickly - I'll carve out some time tomorrow to help test it once the version drops 🙏

[Paul Davies]

@mbonnin just tried dev12 , working perfectly

thanks so much!

[mbonnin]

Ahah you're fast !! I wasn't sure the version was on central yet 😃

[mbonnin]

Thanks for the feedback!