austinried
commented
1 year ago 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.