Simple tool to leverage the ESI Assets endpoint, in a secure and private way, to check status of Rescue Caches owned by you.
The premise is very simple: The ESI (Eve Swagger Interface) provides an endpoint to query all of a character's owned assets, and unlike the in-game Assets dialog, this includes things in wormhole space. If you have sown any EvE-Scout Rescue Caches, this will include those Small Secure Containers AND all of their contents. This means we can utilize this API to answer some specific questions that might come up during our operations: A stranded pilot will be able to utilize a Rescue Cache. Have they accessed and emptied the cache? After a rescue, the stranded pilot did not mention whether they would replenish the cache or not. Have they, or anyone else, replenished it? The rescued pilot did mention that they would replenish the cache. Have they replenished it yet? Absent of this tool, questions like these are left unanswered and instead the cache is simply marked as most likely not-usable. This is mostly a non-issue, as we will likely re-tend the cache before it is needed for a rescue, however "Information is Power" - plus, like many other tools, this one can serve as a backup in case the database isn't updated for whatever reason to reflect the 'Upkeep Required' status of a cache. As a bonus, this tool is a handy way to get statistic information, like how many caches you currently own or what your most popular "fun" item is.
You are correct to be concerned! It's true that this tool only works by looking at all your personal assets (doesn't include wallet). However, the primary guideline being followed with this implementation is that access will always be client side, using a temporary token (implicit flow) that is never stored nor transmitted to any server.
Here is the data flow that is utilized, which you should double check against the code before you run it.
Note: 'localhost' is a special host that always refers to the computer accessing it, also known as loopback - never any external server.
- A simple Express web server is started at http://localhost:1420 that serves routes '/callback' and '/authed'
- A browser will open with a special ESI login URL that includes:
- response_type=token : This means we're in implicit flow, so a token that only lasts an hour or so, not refreshable
- redirect_uri : http://localhost:1420/callback This is the URL our Express server is hosting that the ESI endpoint will redirect to with the token in the URL
- client_id : This is a public identifier for this app from the ESI point of view
- scope : esi-assets.read_assets.v1 : As you will see in the browser, this just tells ESI we need the token to include read_assets scope
- After logging in normally through ESI, you will be redirected with the token to http://localhost:1420/callback
- Express has been configured to host a static page there, which does nothing else but 1) reads the token from the URL, as it is after the hash and therefore not visible to the web server, only the browser and 2) redirect again to http://localhost:1420/authed with the token as a query parameter the web server can read.
- Now at '/authed' the real action can happen, by using the temporary token to build the report. Code in app.js under app.get('/authed') describes this.
To maintain maximum privacy, you should run this application from source after examining that source carefully. To do that, you should just need Node.js and to clone this repository. If 'node app.js' doesn't work straight away, try an 'npm install' first. For convenience, I will also attach some binaries generated by the node utility 'pkg' - however, as far as I know, there's no way for me to prove that the source compiled into those is the same as what you see in this repo, so please understand that the binaries are not the most secure option.