Cached response for get_current_user() returns incorrect data in the case of multiple users

[metazool]

The problem

In a multi-user application, requests to get_current_user are hitting the cache of API requests and returning the user details of the first user to subsequent ones!

It's happening inside requests_cache:

https://github.com/search?q=repo%3Arequests-cache%2Frequests-cache+ignored_parameters&type=commits

Expected behavior

Requests to inat.get_current_user passing JWT token to return the details for the user who the token was issued to

Steps to reproduce the behavior

Log in as user A and obtain a JWT to use the API
Log in as user B, obtain a second JWT, get_current_user hits the cache rather than make a new request

Workarounds

Sending direct requests to api.inaturalist.org/v1/users/me with Authorization headers, bypassing the cache

Environment

• OS & version: [e.g. Debian 10]
• Python version: [e.g. 3.12]
• Pyinaturalist version or branch: [e.g. 0.19 or main branch]

[JWCook]

Oh, interesting. Your project is probably the first to use pyinaturalist with multiple users and authentication.

What ignored_parameters in requests-cache means is "don't use these params/headers for request matching," i.e. redact them (ref). Authorization and a few others are ignored by default to avoid storing plaintext creds in the cache.

In a single-user scenario, your API token may change frequently, but that doesn't affect whether the remote content has changed. However, you can get different results with or without Authorization (an example in the iNat API would be obscured coordinates in GET /observations); so the presence or absence of the header is stored, but not the value.

So that part is working as intended, but not what you want for a multi-user application... specifically for an endpoint where there's nothing (other than the Authorization header) to inform the cache that request is unique from others with the same URL/params. I think you found the one endpoint in the whole iNat API where that's the case, so congrats, it's your lucky day! (EDIT: I guess this would also be the case for the api_token endpoint)

There are a few ways to go about this, depending on what you need:

• Are you comfortable with storing JWTs in the cache (the short-lived API tokens, not permanent user or client credentials)?
• Would you prefer to just skip the cache for get_current_user()?

[metazool]

Thank you, I'm just coming back to this. It was definitely an unexpected behaviour - was unaware of the presence of requests_cache sitting between API calls and iNaturalist until i hit this bug.

I hadn't seen it with the api_token endpoint because I was already doing that without pyinaturalist.

Skipping the cache either by default, or with an optional parameter for calls to get_current_user would be ideal. A JWT cache seems like a route to credentials leakage (I know they're short-lived but don't want to risk getting our application banned)

[JWCook]

You can do both. For individual requests, the latest release has a force_refresh option that will skip the cache:

from pyinaturalist import get_current_user
get_current_user(force_refresh=True)

Or you can disable the cache with a session setting, but that still requires passing it to each API function:

from pyinaturalist import ClientSession
session = ClientSession()
session.settings.disabled = True

get_current_user(session=session)

Global settings like that are a little more convenient with iNatClient:

from pyinaturalist import iNatClient
client = iNatClient()
client.session.settings.disabled = True

client.users.me()

Will one of those options work for you?

[LarytheLord]

Opened a fix for this in #681.

I made get_current_user() bypass cache by default (force_refresh=True, expire_after=DO_NOT_CACHE) while still allowing explicit overrides for advanced use cases.

[JWCook]

I would prefer not to change the default behavior for an individual API function unless there's no workaround. Most use cases for this library are for a single user, with only two multi-user applications than I'm aware of. I'm certainly interested in improving support for these, but preferably at a higher level of abstraction.

For example, I've made a number of changes to support dronefly, in the form of iNatClient and ClientSession features, extra (opt-in) arguments for existing API calls, and changes in the other upstream libraries I maintain (like requests-cache and requests-ratelimiter).

[JWCook]

In the case of caching, pyinat+requests-cache mainly follow a subset of the same rules as a browser cache (RFC 9111, etc.). A browser cache is single-user, and handles multiple profiles by having an isolated cache for each user.

Public caches like CDNs expect request/response headers and request params to inform it what/how to cache, and would avoid a problem like this by simply not caching it.

Combining the use cases of both (shared cache + multiple users) is tricky. Usually the solutions are to either:

• add a header or request param that the cache can use to distinguish between users
• have separate caches per user
• disable the cache