Anyone ever seen this error when use fuel?

javax.net.ssl.SSLHandshakeException: javax.net.ssl.SSLProtocolException: SSL handshake aborted: ssl=0x61e94528: Failure in SSL library, usually a protocol error
10-10 12:09:56.462 22878-22878/app.package.name.App E/AppName: ║ error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure (external/openssl/ssl/s23_clnt.c:741 0x59e916d6:0x00000000)

Seem something belongs to the server since fuel using standard Java api for SSL

I use firebase hosting.

https://stackoverflow.com/questions/29916962/javax-net-ssl-sslhandshakeexception-javax-net-ssl-sslprotocolexception-ssl-han I try to fix it by

fuelManager.setSocketFactory()

but still not working

Can you try this @beze https://stackoverflow.com/questions/26633349/disable-ssl-as-a-protocol-in-httpsurlconnection ?

I tried this too but still not working. Thanks simple smile

We haven't mentioned it, but Fuel has passed 1k stars a while ago K

after doing an async request, fuel keeps hanging..

hello!

I am trying to organize an OAuth2-similar authorization with Fuel

the auth goes like this: first we receive a 200 with csrf, and then we should post another request with credentials, to which the server responds with 302

the 302 response contains the session cookie that we want to save for further requests

we have implemented the saving mechanism with response interceptors

however, there's a problem

the response interceptors chain short-circuits in case of getting a redirect

so, effectively we are unable to receive and save the cookie

what should we do?

I also think that the HTTP response validation interceptor that prohibits running any further interceptors is not what allows for an easy customization when writing some API client

since we may want to intercept all kinds of responses, with any HTTP code

is it somehow possible to organize interception of what we get in the 302 response and, possibly even, some other HTTP codes?

we've been able to workaround this problem by extending FuelManager with

clearAllResponseInterceptors()

and

installDefaultResponseInterceptors()

the methods do exactly what their names say

so, before the 302 redirect we nuke all the interceptors

then we install the one we need, which does our authorization job on 302

and then we nuke everything again and restore the default settings

well...

it works

but it does not feel right.. probably, the interceptors mechanism should be improved to allow more customization out-of-the-box, with an explicit warning that "by default all your intercetors are ignored in case of 302"

or the redirect interceptor should be more clever

I think it is not uncommon to send auth tokens with a redirect, I've seen this a number of times already