Properly handle expired keys

[XanderStrike]

Trakt is being slammed at all hours by webhook requests from people who's Trakt keys are invalid.

This causes Plaxt to attempt to refresh the keys, which then returns a 401 with the message "The provided authorization grant is invalid, expired, revoked, does not match the redirection URI used in the authorization request, or was issued to another client."

This happens repeatedly, every time that user sends a webhook to Plaxt. There is no way to recover from this because the refresh keys have been made invalid. The cause is also impossible to determine, Trakt is not sufficiently explicit with their errors, and there is no way to contact the owners of these keys to get them to stop sending webhooks.

This may have knock on effects, because Plaxt is basically spamming the Trakt api with invalid and useless requests. It might be the cause of some of the 502s being reported.

The best we can do is mitigate the damage. We should delete user records that have unrecoverable invalid keys. This way we'll stop sending so many API requests to Trakt and hopefully bother them less.

[avnigo]

I just came across this issue when I realized Plaxt stopped working for me, and have since reauthorized manually -- with some hiccups (more on that below).

Do we know the reason Plaxt fails to refresh the keys? The 401 error I got in the Plaxt log (the one you quoted), matched the error I got when I tried reauthorizing manually, except that that error was specifically and only about a "malformed redirect URI".

I had some trouble getting Trakt to redirect properly based on the configuration I had. The only configuration that finally worked for me was setting ALLOWED_HOSTNAMES=http://domain:port/authorize in the docker-compose file, and adding two redirect URIs to the Trakt API app: http://domain:port and http://domain:port/authorize.

I believe I tried all the combinations of keeping or removing the /authorize from the docker-compose file and the redirect URIs in the Trakt API app, but nothing worked for me until I thought I'd try both redirects.

I, then, deleted the new manually generated keys to check if the automatic refresh would work now that the redirect seemed to be fixed, but I was still getting the 401 error.

Could it be that the 401 error is because the redirects aren't configured properly? What's the actual way of configuring this anyway?

[avnigo]

I believe what is causing this issue is that Plaxt is not storing the refreshed tokens properly after asking Trakt to refresh them, so any consequent requests with the old tokens are now 401 invalid.

Seeing as the token is not expired at first, but outdated after 1400 hours, it is only invalidated at the time of the first request to refresh. The token would still be valid if the request to refresh had failed, since the token had not yet expired. However, since the token is invalid right after the refresh, the refresh request must've been successful.

Therefore, it must mean that Plaxt fails to store/receive the new refresh and access tokens, and the UpdateUser function never actually runs as the update time is also not updated in the store.

As my knowledge of golang is very limited, and debugging wasn't as accessible in docker without too much extra effort on my setup, I wrote a quick script in python to refresh the tokens and overwrite them in the disk store based on the Trakt API reference, and refreshing works just fine. So as a proof of concept, I believe the issue is with Plaxt not storing the refreshed tokens.

I know issue #45 concerns itself with the expired keys slamming the Trakt API, so removing those invalid keys is the work that needs to be done, but I believe the issue runs deeper, and can be fixed for new users by properly storing the refreshed tokens.

[avnigo]

If anyone happens to read this, I believe the reason Plaxt fails to write the refreshed token is due to permission issues of the disk store. In my default setup of this current docker image, the disk store shared volume is mounted as root, even though it is not ran as root.

If I understand correctly, I believe the image must be rebuilt with user and group id arguments, but to my limited knowledge of docker, I don't know if that interferes with the fact that it's built FROM scratch.