supertokens / supertokens-android Goto Github PK

SuperTokens.withApiDomain(...).withApiBasePath(...).withSessionExipredStatusCode(..).initialise();

We can do this way later. Just making an issue for now

• Auto generated docs
• In our guides
• Readme changes for this repo

• "refresh session"
• "test that unauthorised event is fired when calling protected route without a session"
• "test that after login, and clearing all cookies, if we query a protected route, it fires unauthorised event"
• "test rid is there"
• "signout with expired access token"
• "signout with not expired access token"
• "update jwt data"
• Need to remove "httpUrlConnection_testThatDeviceInfoIsBeingSent"
• "test that attemptRefreshingSession is working correctly"
• "test that if via interception, initially an endpoint is hit just twice in case of access token expiary"
• "test interception should not happen when domain is not the one that they gave"
• "test that an api call without cookies throws session expire, refresh api is not called and 401 is the output"
• "test that via interception initially an endpoint is just hit once in case of valid access token"
• "test that if multiple interceptors are there, they should all work"
• "refresh session with invalid tokens should clear all cookies"

From axios2.test.js

• "refresh session, signing key interval change"
• "refresh session endpoint responding with 500 rejects original request with axios error"
• "API returning 401 will not call refresh after logout"
• "refresh session endpoint responding with 401 rejects original call with axios error"
• "no refresh call after 401 response that removes session"
• "original endpoint responding with 500 should not call refresh without cookies"
• "refresh throwing an error with empty body doesn't cause an error"
• "test when ACCESS_TOKEN_PAYLOAD_UPDATED is fired"
• "test ACCESS_TOKEN_PAYLOAD_UPDATED when updated with handle"
• Test manuallySetCookiesFromResponse

In accordance to this pull request: supertokens/supertokens-website#22

Refer to the discussion here: supertokens/supertokens-website#17

The issue seems to be:

• the app sends a request and adds Authorization header manually, set to the current access token
• we start interception and create a copy of the request
• we remove the authorization header and re-add if necessary since it matches the current access token
• we get a 401
• we call refresh, which updates the tokens
• start the loop again
• we create a new copy of the original request
• we no overwrite the existing authorization header since it doesn't match what we have locally (since it updated)

The issue is similar to what was resolved here: https://github.com/supertokens/supertokens-react-native/pull/123/files#diff-08906753e0eb5ab2b91ee375361349ad892b18d17afc2e22fcdd206cd1ecb148

TODOs:

1. Please add a test that checks if this issue is present
2. Fix the issue by always removing the header if we removed it to the first iteration

In this and this function, we need to change != 200 to >= 300

Summary

The SDKs logic for adding headers, cookies etc when making network requests and the logic to handle response headers and session expiration needs to be updated

TODOs

• Update the config parameters that the SDK accepts during SuperTokens.init
• Add Pre API hooks Add a way to add custom headers for requests made by the SDK
• Add the event handler (OnHandleEvent)
• Add logic to set/remove the front token
• Make sure the request logic (interception, reading/setting headers etc) is up to date
• Change the package name to use com.supertokens instead of io.supertokens
• Missing functions to expose:
  • getUserId
  • getAccessTokenPayloadSecurely
  • attemptRefreshingSession
  • signOut
• Add logic for doNotDoInterception
• Remove adding of PACKAGE_PLATFORM and VERSION_NAME
• Remove preConnectCallback [ We need this for HTTPUrlConnection so users can add custom properties to the connection object]
• Need to add credentials include in the request header? [Not required]
• Add header for rid and set it to anti-csrf if the user has not done that already
• Add front-token:
  • When you are setting anti-csrf token in doRequest
  • Post refresh API call
• Remove front-token:
  • When we remove anti-csrf
  • Finally block of refresh function if the idRefreshToken doesn't exist
• Remove need for handleUnauthorised function
• Remove this if statement: https://github.com/supertokens/supertokens-android/blob/update-init-logic/app/src/main/java/io/supertokens/session/SuperTokensHttpURLConnection.java#L118

if ( preRequestIdRefreshToken == null ) {
            String idRefreshToken = IdRefreshToken.getToken(applicationContext);
            return idRefreshToken != null;
        }

• When refresh is called, add rid: session and fdi-version headers
• In the finally block of function that calls refresh API, we should check if idRefreshToken exists, and if not, remove anti-csrf and frontend token
• Verify if locking is needed in token classes
• Override / recipeImplementation abstraction
• User context
• Upgrade android properties
  • Test with latest target sdk and compile sdk versions and update
  • Update to latest okhttp and retrofit versions
  • Upgrade to latest gradle?
  • Check if min sdk version needs to change
  • Double check progaurd rules

Cookies between OkHttp3 clients and HttpURLConnection requests are not guaranteed to be shared. As a result when using sessions with OkHttp3/Retrofit SuperTokens.signOut does not actually clear the session.

This is because the signout function internally uses httpurlconnection.

To solve this problem, it is best that the sign out API is called directly without using a helper function. The SuperTokens.signOut function should be marked as deprecated

Summary

The SDK logic for when SuperTokens.init is called needs to be updated to:

• Accept the right parameters
• Use a config instead of individual static variables

Hello,
I'm using OkHttp3/Retrofit.
About 20 minutes after sign in, doesSessionExist return false.
Is it the same issue as #33 (comment) ?