kbremner / read-more-api Goto Github PK

The API endpoints will return 500 errors unless an appsettings.local.json file is added with a POCKET_CONSUMER_KEY variable.

Need instructions on how to create this consumer key and add it. Should also stipulate how to update this URL in the chrome extension README.

Some endpoints require an access token to be provided. This access token consists of the generated GUID for a PocketAccount entity that has been protected using the Data Protection APIs.

It is expected that this access token would remain valid until the user revokes our access rights to their pocket account.

Keys generated by the Data Protection APIs have an expiry date, with a new key generated when the previous key has expired.

All of the endpoints that require an access token don't at any point regenerate it. As such, at some point, the access token will expire as the key used to generate it will no longer be valid (there is a grace period between when a key stops being used to protect but can still be used to unprotect).

Current impact is that a user will be forced to re-authenticate every time a key expires (every 14 days?).

We currently use the access token to evaluate what is being access and if the caller can access it. As an alternative example, the Pocket API requires a consumer key to identify what is being accessed and an access token to determine if the caller has permission to access it.

Possible options:

1. Stick with the current approach, accept that users will have to re-authenticate regularly.
2. Return a new access token from each API call, generated by protecting the PocketAccount ID again.
3. Authenticate users via an alternative mechanism (i.e. JSON Web Tokens (JWT))

As part of the OAuth flow with Pocket, the user is redirected to a page on the Pocket website, accessing them to confirm that they wish to grant us access rights to their account.

Expected behaviour if the user rejects this request is that the popup should show a suitable error message and a prompt to try again.
Actual behaviour is that the popup does nothing and must be reinstalled to trigger a new authentication attempt.

This API should still redirect to the caller if access is denied, with an appropriate error query parameter.

Every time a user authenticates, a new user is created in the database. However, we should detect that a user already has an account and update rather than creating a new one.

Unfortunately, we don't get access to a user ID. We do get a username, but this can be changed by the user. When the user attempts to change their pocket username, they are warned that they will have to re-login to connected apps, suggesting that the username is the suggested way of identifying returning users.

We should use the username to detect if a user is returning versus logging in for the first time.