AuthenticationClient methods imply Async about okta-auth-java HOT 3 OPEN

@mfulgo Thanks! this is a great place for that discussion. This thought had crossed my mind, but I wasn't sure how developers would prefer to consume it. My preference would be returning void with the handler as an argument. Though your suggestion above is nice too.

Neither of these options require the method to be async, it all depends on how the method is called. This lib could be used in a CLI or a webapp.

What type of application were you thinking about using this lib with?

Great feed back, thanks!

from okta-auth-java.

@bdemers Perfect. So, in my particular use case, I'm implementing a proxy/broker. For me, the problem with the handler is that it actually gets in the way of returning a response, but a void return would be worse.

var response: AuthenticationResponse = null
val handler = new AuthenticationStateHandlerAdapter {
  override def handleUnknown(authResp: AuthenticationResponse) = {
    response = tweakAuthResponse(authResp)
  }
}
client.authenticate(user, pass, relayState) // Assuming it returns void
ok(response)

However, if it returns the AuthenticationResponse, it simplifies quite a bit:

val authResp = client.authenticate(user, pass, relayState)
val response = tweakAuthResponse(authResp)
ok(response)
// Or just...
ok(tweakAuthResponse(client.authenticate(user, pass, relayState)))

This gets a little more complicated when dealing with Futures and thread pools, but I think the second approach gives you more control over that as well. (i.e. What context is executing the http request vs handling the response. If the client methods take in the handler, the only option is to have the client thread execute the handler methods.)

from okta-auth-java.

Thanks @mfulgo great examples and points! I'll chew this over a bit more.

from okta-auth-java.