At the moment, if you want to serve your applications via an account, the API key needs to go into [account] section of your configuration file. Depending on the type of application, how it's being served, and who the audience is, this could be an issue. If, for example, some application that's being served allows a way of viewing the content of a file in the current directory[^1], this would mean that anyone with the URL could get the API key for that account.
I think there's a couple of things we may want to do here:
Include in any documentation a clear description of how this is something to keep in mind, and that users should think carefully about what applications they serve and who they give access to.
Consider adding other routes via which the API key can be provided to textual-web (for example, perhaps from an environment variable, or a keychain, or ~/.authinfo, or...).
[^1]: There are of course more general issues about applications that provide filesystem access; we may want to think about a very general "best practices" document when it comes to applications and security at some point.
At the moment, if you want to serve your applications via an account, the API key needs to go into
[account]section of your configuration file. Depending on the type of application, how it's being served, and who the audience is, this could be an issue. If, for example, some application that's being served allows a way of viewing the content of a file in the current directory[^1], this would mean that anyone with the URL could get the API key for that account.I think there's a couple of things we may want to do here:
textual-web(for example, perhaps from an environment variable, or a keychain, or~/.authinfo, or...).[^1]: There are of course more general issues about applications that provide filesystem access; we may want to think about a very general "best practices" document when it comes to applications and security at some point.