[ENHANCEMENTS] - RESTful API to list or create proxy records

[freedbygrace]

The title should say it all, but this would be an amazing feature to be able to programmatically list and create proxy records from external applications, scripts, etc. This would allow for some serious automated provisioning.

Lastly, another off shoot idea would be to create proxy entries with docker container labels, similar to Traefik. If this is out of scope totally from the overall design, that is totally fine also.

[tobychui]

@freedbygrace Interesting idea, but in what use cases this will be helpful? I do think in some use cases, this might be helpful, but I am a bit worry about the security risk associate with this feature.

[freedbygrace]

Hey, so sorry for the late reply. Been a busy few weeks. I don't believe security would be any major issue here as long as best practices are followed and or considered at the very least whilst implementing this. I list that I think below.

The API would be useful for when rapidly spinning up VM instances, they can automatically exposed using client side scripts. A device comes online and says "expose me at this external hostname, internally directed to this service I am running on this port with these options."

1. API is not enabled by default and must be implicitly enabled by a user with the appropriate rights.

2. Tokens / API keys should be objects that get assigned rights the same way as users and not assigned to user accounts themselves. This way, a token can be granted read only on 1 or more Proxy Rules and another token can be granted read/write on 1 or more proxy rules and other objects.

3. Tokens should have the option to have expiration dates and also not expire. Tokens should also be able to be revoked.

4. API should follow CRUD standard and generate its documentation automatically.

5. API should be able to be customized such as a proxy endpoint, so you can set similar rules that Zoraxy offers.

6. API tokens should be submitted in the API request headers and query should be in the request body and not in the URL query strings so that nothing is exposed in the packet level when using proper encryption.

With these things in place initially and refined over time, this should make security a non issue from a product perspective. Should a user mishandle the usage of API tokens that put their instance at risk, then that is on them. Even the fact that this is an application that will most likely be exposed to the internet in some way, you have already stepped well and beyond into the security concern realm.

Does any of this help?