auto-ssl / auto-ssl/lua-resty-auto-ssl

Allow storage adapters optionally specify delimiters

Open
#204 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Lua
Stars
2k
Forks
184
PR merge metrics
No merged PRs in 30d

Description

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](https://github.com/GUI/lua-resty-auto-ssl/blob/9d43c23af16203b5f94b270fde4b33a77b9cabde/lib/resty/auto-ssl/storage_adapters/redis.lua#L5). 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](https://github.com/GUI/lua-resty-auto-ssl/blob/b2c0d8dbb6ed9ac61e75f62e273269de1ac35511/lib/resty/auto-ssl/storage.lua) to `:`

Example:

```lua
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 https://github.com/fititnt/ap-application-load-balancer/issues/25#issuecomment-559617348,

![69834723-fbbae280-121a-11ea-8cd4-48371a662279](https://user-images.githubusercontent.com/812299/69908540-d40a7c80-13ca-11ea-8fcd-fd814bafeed0.png)

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.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by comparing lib/resty/auto-ssl/storage.lua with the adapter implementations, especially lib/resty/auto-ssl/storage_adapters/redis.lua and consul.lua. Trace every hardcoded colon used in storage keys and review the related #203 context. Done means adapters can optionally define a delimiter while existing adapters retain the current behavior and all affected keys use the selected delimiter.

Written by the indexing model from the issue text.

Assessment

Tech stack
lua
Domain
backend, databases
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.