Allow storage adapters optionally specify delimiters

[fititnt]

Related #203

When developing storage_adapters for lua-resty-auto-ssl, the only part that is possible to customize the separator on prefixed_key inside the redis.lua. This is how I'm implementing on consul.lua.

But for both file and redis adapter, the other separators are hardcoded on on storage.lua to :

Example:

return self.adapter:get(domain .. ":challenge:" .. path)
--- ...
local json, err = self.adapter:get(domain .. ":latest")

--- ...
local key = domain .. ":issue_cert_lock"

--- ...
local key = domain .. ":issue_cert_lock"

So, as cited here fititnt/ap-application-load-balancer#25 (comment),

At this moment, at least is possible to enforce a prefix for all lua-resty-auto-ssl concent, but all other content (for each domain) are keep on the same folder.

Does the lack of specifying a delimiter affect the basic funcionality of Consul adapter?

No. It works. The #203 does not require this.

This only would affect usage with Consul on "more enterprise" or places with huge number of keys managed by a single data storage with strong ACL.

Strong cases for make it flexible

• Consul can allow Access Control List based on key prefixes (but this requires change : to /
  • See https://www.consul.io/docs/acl/acl-rules.html
  • At this moment, is only possible to give entire access to all keys or none key
  • If this feature is implemented, could be possible, for example, to give not only difference betwen write and reads, but also give the oportunity to deny or allow based on specific domain
    • Even if a centralized storage contain all keys, some Consul clients (and by extension a node running OpenResty) could write and/or read only some domains

There is not so strong cases for this, but just to mention:

• One lazy way to implement what domain could be accepted or not (at least for Consul adapter) could be just deny writes. for some paths
  • Not that I would implement this way, but is one way.
  • Maybe this could be implemented at another layer or method before consul.lua is called. I will think this later
• If for some reason too much keys are created and not deleted, at least on Consul there is no "batch delete" without prefixed keys with "/". Much less clicks on the UI using this way.
  • Note: the screenshot was from an older version of consul.lua. The new one is already deleting the locks and challanges.