hey, I'm making <thing> and for <thing> I want to have some kind of user account. I also don't want to do my own user accounts, so the itch serverside api seems like a perfect fit! So this is just a bunch of notes on my experience getting everything integrated, from the client to the server side.
I started here, which is pretty clear enough:
https://itch.io/docs/api/serverside
To know where my jwt token (yeah I know it's json web token token you can't stop me) will come from, it links me to https://itch.io/docs/itch/integrating/api/. This is a little odd, because the information I actually want is on https://itch.io/docs/itch/integrating/manifest-actions.html. Ideally I'd be able to post an anchor link to the "API Key and scoping" section, but I can't tell if the headers actually have anchor links? either way, this is the most pertinent info and I can work backwards to find out what a manifest even is.
When I get there, all the documentation there uses the term API key. In practice, the thing that's in ITCHIO_API_KEY is a jwt token, which is what I would expect, and not a persistent API key.
Then, next step in implementation is to make and test a client that can do the right thing with an ITCHIO_API_KEY. The only way I could find to do this was to actually create an itch project for my app, upload it with the manifest, and then run it. That makes sense, but it adds a lot of time to the iteration cycle while developing. If there were a way to use butler to treat a random folder as an itch app and run it, or even better a way to have butler just return a jwt token, it would be much simpler for me to test my auth code, and maybe even do some automated testing.
So in addition to authenticating users, I'd like to make sure that a user should have access to my game before letting them in. The way to do that then, I guess, is to use the download_key endpoint. So I go ahead and test it, and to my surprise the account that created the itch project to begin with doesn't have a download key, which is true, I guess? I just went ahead and generated a key and claimed it on the same account, and then my code worked fine. Is there/should there be a more inclusive endpoint that can include anybody who can download the game on the app, including maybe press accounts? For testing, I can just turn this piece off, that's not a big deal, just wanted to check if this approach is valid.
And then some not-discussed things that I figure I should ask. I 100% don't expect a problem with these at my scale, just that it puts my mind at ease knowing that an answer exists.
1. Rate limits? Right now, I just fire off a request, and if there's a failure of any kind that's bubbled up to the player. If I knew there was a rate limit, I could enforce it on my side and save some traffic, or even better implement a queuing/retry system.
2. Revoked keys? the API docs mention the possibility of a revoked download key. This makes me sad, because I wanted to cache off the download keys: if a player has authenticated successfully once I assumed I could just treat them as having owned the game and save an http request. What kind of situations would this happen under and could I get away with just querying to get a full list of revoked keys every once and a while?