Enable access to response headers ( i.e. rate limit headers )

I’m submitting a

• bug report
• feature request

Background info

We have a use case in which we need to know when we’re approaching our organisation’s rate limits for user logins / user creation, etc. This information is returned in the headers X-Rate-Limit-Limit, X-Rate-Limit-Remaining, X-Rate-Limit-Reset for most api calls. Using either okta-sdk-java or okta-auth-java sdk, all responses contain only the resource body returned by Okta; all headers are stripped - for instance the AuthenticationResponse object after logging in a user, or the com.okta.sdk.resource.user.User object after creating an user.

Expected behavior

All resources should provide access to the response’s headers. Making the API calls directly, all headers are present in the response, something the SDK doesn’t provide access to.

What went wrong?

There is no way to access the response’s headers. Looking into the code - in com/okta/sdk/impl/ds/DefaultDataStore.java, the function

private <T extends Resource, R extends Resource> R save(String href,
                                                            final T resource,
                                                            final T parentResource,
                                                            HttpHeaders requestHeaders,
                                                            final Class<? extends R> returnType,
                                                            final QueryString qs,
                                                            final boolean create)

makes the request to Okta at line 331, but then complete ignores the contents of the response headers:

            Response response = execute(request);
            Map<String, Object> responseBody = getBody(response);
            if (Collections.isEmpty(responseBody)) {
                // Fix for https://github.com/stormpath/stormpath-sdk-java/issues/218
                // Okta response with 200 for deactivate requests (i.e. /api/v1/apps/<id>/lifecycle/deactivate)
                if (response.getHttpStatus() == 202
                        || response.getHttpStatus() == 200
                        || response.getHttpStatus() == 204) {
                    //202 means that the request has been accepted for processing, but the processing has not been completed. Therefore we do not have a response setBody.
                    responseBody = java.util.Collections.emptyMap();
                } else {
                    throw new IllegalStateException("Unable to obtain resource data from the API server.");
                }
            }

            ResourceAction responseAction = getPostAction(req, response);

            return new DefaultResourceDataResult(responseAction, uri1, returnType, responseBody);

Steps to reproduce

Create or log in a user using the SDKs

SDK Version

4.0.0

[mattdrees]

Near as I can tell the only way to get it is to log the rate limit headers on a constant basis, and capture/alert on that.

I think this isn’t strictly true, anymore; Okta released a rate limit dashboard recently that might be pretty helpful.

[dziedrius]

As others mentioned, getting exception/seeing in dashboard is too late already. We have background jobs, syncing information from time to time and they don’t have same priority as user initiated requests, hence we would prefer background job sleep a bit until rate limit is recovered than kill rate completely so that users would start getting errors. okta terraform provider seems to implement this nicely by having max requests setting, where you set percent of rate limit used before throttling kicks in.