List cached accounts

[Gjum]

Is your feature request related to a problem? Please describe.

I want to provide the user with a convenient selection menu for all cached accounts that she has previously used.

None of the ABC_*-cache.json files seem to contain any reference to the user identifier passed when calling Authflow, nor the resolved Minecraft username/UUID.

Looking up each cache's username one by one would delay the application startup and has me worried about Microsoft API rate limits.

Describe the solution you'd like

User identifier (and/or Minecraft username/UUID) is cached together with the ABC_*-cache.json files

Describe alternatives you've considered

Tracking the past used accounts in a separate file maintained by the app; this would mean that accounts cached by one app would not be known to another app on the same machine.

[extremeheat]

Where and how exactly the cached data are stored for accounts is really an implementation detail, not something apart of the stable API. It's not indexed anywhere because the code is designed to retrieve and cache with the expectation that the retrieval may fail for any reason, like the cache not existing or expiring.

If stored in the file system for example the expectation is the data would be stored in a temporary folder (like /tmp or %temp%) that could be periodically reclaimed by the system. Or if running in the browser that data could be stored in local storage.

Just because data may be stored in the cache doesn't mean the tokens stored as valid, and the only way to know is to actively try and authenticate with them. For your use case I'd recommend making a separate accounts.json for your app. However, I think it would be possible with some work to expose a method to just check hasValidXCache(identifier, cache) just looking at token expiry dates.

[extremeheat]

Looking into how we can better account for the cached tokens. Right now our caching code doesn't have a standard interface to check if the cache is outdated or not, so validity checks are scattered throughout the *TokenManagers. This isn't good so we need to move that logic into the cache API.

[extremeheat]

For the generic interface I'm thinking of adding set/get functions to Cache. This would be a breaking change, but allow for caches to know when the contents of the cache are expired and when the cache can be deleted.

  export interface Cache {
    // old
    reset(): Promise<void>
    getCached(): Promise<any>
    setCached(value: any): Promise<void>
    setCachedPartial(value: any): Promise<void>

    // new:
    set(key: string, value: any, options: { expiresOn?: number, obtainedOn?: number }): Promise<void>
    get(key: string): Promise<any>

    // Removes all expired keys
    cleanupExpired(): Promise<void>
    isEmpty(): Promise<boolean>
  }

And not part of the cache API, but for our file system implementation (FileCache) we can add in static function like

  static cleanupExpiredCaches (cacheDir) {
    const caches = FileCache.listCaches(cacheDir)
    for (const cache of caches) {
      cache.cleanupExpired()
      if (cache.isEmpty()) {
        FileCache.destroy(cache.cacheLocation)
      }
    }
  }