You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since the API/server is made public, I was just thinking it would be nice to be like those APIs that have authentication in order to use them, via API tokens (e.g developer/API keys from UI based signup for developer or API usage program, or auto-generated token on each call to some login API that's related to this service's API).
This would be more for self hosted use, but could be considered with the public hosted service in the future.
With this kind of support/implementation, IP based limiting may not be necessary since the token authenticates a legitimate use of the API and we are assuming/expected such, unless the token was hijacked/spoofed of course.
In any case, this is just a suggestion, and other 3rd parties can implement and put in the pull request instead of this specifically targeting the original project. Or someone can mention how to build that in (with integration with another service) if it doesn't really require code changes to the server itself.
The text was updated successfully, but these errors were encountered:
Right now we have manually generated API tokens for removing rate limiting, in server/keys.json (see server/keys_example.json). I generally just add them when people email me for a rate increase. Agreed that autogenerating these keys or some formal signup/review process would be nice.
Since the API/server is made public, I was just thinking it would be nice to be like those APIs that have authentication in order to use them, via API tokens (e.g developer/API keys from UI based signup for developer or API usage program, or auto-generated token on each call to some login API that's related to this service's API).
This would be more for self hosted use, but could be considered with the public hosted service in the future.
With this kind of support/implementation, IP based limiting may not be necessary since the token authenticates a legitimate use of the API and we are assuming/expected such, unless the token was hijacked/spoofed of course.
In any case, this is just a suggestion, and other 3rd parties can implement and put in the pull request instead of this specifically targeting the original project. Or someone can mention how to build that in (with integration with another service) if it doesn't really require code changes to the server itself.
The text was updated successfully, but these errors were encountered: