Problem Statement:
A user could receive and view data that is not theirs, and we must prevent this from happening in a secure application. Here is a diagram of how this could happen:
Flow Diagram of the Session Mismatch Issue
Implementation options with Retrofit 2 and okhttp 3:
Option 1:
Write a custom Retrofit 2 CallAdapter that blocks the response from being processed or passes an exception to the onFailure() method.
- PROS:
- Great if you use Retrofit 2 exclusively for session sensitive calls.
- This can prevent the callback from being invoked, or you could call Retrofit 2’s onFailure() method.
- CONS:
- Retrofit 2 CallAdapter is complex and you have to write one for both plain Callbacks as well as for RxJava (if you are using both).
- We’d have to copy the existing CallAdapter implementation in retrofit2.ExecutorCallAdapterFactory and modify it as it’s a final class.
- This only works for Retrofit 2 calls, but not all networking calls made through okhttp 3.
Option 2:
When the client session is invalidated, use okhttp 3’s Dispatcher to cancel all running and queued calls.
- PROS:
- Very effective. All calls would immediately be cancelled.
- CONS:
- If there is a call like “Update Profile” that is still occurring, it would be cancelled, which is not desirable.
- If there is an unauthenticated call happening, you’d have to ensure that was being executed on non session sensitive Retrofit 2 or okhttp 3 instance to avoid unwanted termination.
Option 3:
Same as the previous option, but instead occurs when a new client session is started, instead of when an old one ends.
- PROS:
- Very effective. All calls would immediately be cancelled.
- CONS:
- You would have to ensure this code got run before you kicked off any session sensitive calls, otherwise they would be immediately cancelled.
- If there is an unauthenticated call happening in the background, you’d have to ensure that was being executed on non session sensitive Retrofit 2 or okhttp 3 instance to avoid unwanted termination.
Option 4:
Using an okhttp 3 Network Interceptor to return back an HTTP Response with a custom response code like 999 and removing the response body.
- PROS:
- Will work for:
- All okhttp 3 calls.
- Retrofit 2 Callback calls.
- Retrofit 2 RxJava calls.
- Will work for:
- CONS:
- It will appear like the HTTP response came back from the server so you will have to have custom logic in your response handler to check and see if this response has a HTTP status code of 999.
- It feels a little “hacky”… but would prevent the security hole.
Option 5: (My Choice)
Using an okhttp 3 Network Interceptor to throw a custom SessionMismatchException when this problem is detected, and handle the Exception appropriately.
- PROS:
- Will work for:
- All okhttp 3 calls
- Retrofit 2 Callback Calls
- Retrofit 2 RxJava Calls
- This is truly an “Exception” scenario, so this makes sense.
- The request is executed fully, but will not be received by the client. (This could be a “con” depending on your use case)
- Will work for:
- CONS:
- You must code your onFailure and onError handlers to appropriately handle this SessionMismatchException type.
- If you just extend IOException, okhttp 3 will by default retry the HTTP call. However, if you extend java.net.SocketTimeoutException, okhttp 3 will not retry.
My Choice: Option 5, throwing a custom SessionMismatchException. This seemed to be the most flexible and intuitive since this truly is an Exception/Failure case. I’ve provided a sample implementation of this below.
Assumption: You have a “SessionManager” in your Android code which is aware of the current session.
Let me know if this was helpful, or if you’d do something different on Twitter at @HandstandSam
