Currently we have caching disabled for everything under /api/v1/authorization. Though the Authorization model does define a cache key that should work ... hashing your token-auth account ids.
Should consider enabling caching there. But it's not entirely straightforward. Using Publish/CMS locally, I saw a lot of 500s coming from hal_api-rails with caching enabled. Appears to be endpoints that manually set the hal_api-rails instance variables. For instance:
class Api::Auth::SeriesController < Api::SeriesController
def resources_base
@series ||= authorization.token_auth_series
end
end
This doesn't appear to play well with kaminari, as we haven't decorated that @series with paging (or anything else). Maybe this is just the wrong way to override resources base?
But even after cleaning those up, still saw some other bugs pop up. May take some work to track those all down.
Currently we have caching disabled for everything under
/api/v1/authorization
. Though the Authorization model does define a cache key that should work ... hashing your token-auth account ids.Should consider enabling caching there. But it's not entirely straightforward. Using Publish/CMS locally, I saw a lot of 500s coming from hal_api-rails with caching enabled. Appears to be endpoints that manually set the hal_api-rails instance variables. For instance:
This doesn't appear to play well with kaminari, as we haven't decorated that
@series
with paging (or anything else). Maybe this is just the wrong way to override resources base?But even after cleaning those up, still saw some other bugs pop up. May take some work to track those all down.