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
Add support for setting an API key that would be included in the "X-APIkey" header in every request sent to the server. This would allow users to add another layer of security to their backends by rejecting requests that do not include their private API key as described in this stackoverflow post.
The use-case is that many people protect backend services using an authentication framework but it's usually necessary to bypass this authentication for any mobile apps that require access to an API since it's not possible to go through the browser-based authentication flow within the app. These "naked endpoints" are protected only by the backend application's built-in authentication which is likely not as hardened as the dedicated auth framework.
The text was updated successfully, but these errors were encountered:
kyle-cackett
changed the title
Support for setting an API key included in all requests made to the server
[Feature Request] Support for setting an API key included in all requests made to the server
Nov 18, 2022
This seems a little bit out of scope for a client, but I can see the use case for it, especially in a self-hosted environment. I would probably want the implementation to be a little more generic though, with just allowing any number of custom headers to be set for a server, with user-defined header names/values.
I'm not sure if this will make it into the initial 2.0.0 release but it's something I could see adding support for.
Add support for setting an API key that would be included in the "X-APIkey" header in every request sent to the server. This would allow users to add another layer of security to their backends by rejecting requests that do not include their private API key as described in this stackoverflow post.
The use-case is that many people protect backend services using an authentication framework but it's usually necessary to bypass this authentication for any mobile apps that require access to an API since it's not possible to go through the browser-based authentication flow within the app. These "naked endpoints" are protected only by the backend application's built-in authentication which is likely not as hardened as the dedicated auth framework.
The text was updated successfully, but these errors were encountered: