Retrofit and auto relogin on a 401 response

One day while sitting at my desk minding my own code I suddenly found myself under siege by a evil api that only allowed my Set-Cookie header to live for 5 minutes. Since I consider myself to be a champion for the week and meek I could not let this pass, so I said to myself and the api, “You shall not pass!”. This was confusing to both me and the api since I was the one who where trying to pass (some data to the api that is).

After a little while I had built up enough courage to confront the evil api and bring order to the 5 minute lifetime of the Set-Cookie header. In preparation for the encounter with the evil api I have to arm myself, my weapon of choice was to be a “okhttp3.Authenticator”. Well, perhaps not MY choice but this was what the mighty SO wizards pointed me towards and therefor what I picked up instead of my trusty Gigant spiked club +2.

After learning about the possibility to add the”okhttp3.Authenticator” of my own implementation to the OkHttpClient I was confident that I would soon have the mighty api beaten and emerge victorious from the depths of the code cave where the api lay waiting for me (as soon as the api heard about me getting help from the mighty SO wizards it fled like a coward to the deepest dungeons in the code cave).

After putting together a mighty scroll of java imbued with the power to throw IOExceptions I knew I was ready. A excerpt of the scroll is posted below for others who might encounter similar apis while exploring the code cave.

class JSessionIdAuthenticator implements Authenticator {
    public static final String SET_COOKIE = "Set-Cookie";

    public Request authenticate(Route route, Response response) throws IOException {
        IRetrofitService retrofitService = autoLoginRetrofit.create(IRetrofitService.class);
        String loginEmail = SharedPreferences.readLoginEmail();
        String loginPassword = SharedPreferences.readLoginPassword();
        Call call = retrofitService.postAutoLogin(loginEmail, loginPassword);
        Headers headers = call.execute().headers();
        String authToken = headers.get(SET_COOKIE);
        return response.request().newBuilder()
                .header(SET_COOKIE, authToken)
Retrofit autoLoginRetrofit = new Retrofit.Builder()

When properly injected in theOkHttpClient this spell will auto cast itself anytime the evil api responds with 401 response code, so even the nastiest apis should be beaten flat with this. When cast the spell will do a login and then pickup the Set-Cookie header in the api response and copy the new value over to the original request and then resend the original request, thus vanquishing the evil api once and for all.

Do drop a comment if you want me to expand on the story of the evil api or just have some question regarding this or other sorcery related topics.

This Post Has 2 Comments

  1. Andreas

    Isn’t it a bad security practice to store the password on the client to begin with?

    1. Carl-Emil Kjellstrand

      It is, sometimes the backend api will force the frontend to do bad things. If you have got any ideas of how to improve on this, please share!

Leave a Reply