TTL for brute force protection for public shares

[jvillafanez]

Describe the bug

For brute force protection, we're basically storing timestamps, and those timestamps are cleanup on share access (if needed). However, if the share is accessed, the data will remain forever.
Although this isn't a problem, we might end with a lot of storage data used for nothing because such data could be obsolete.

Steps to reproduce

There are no real steps other than entering the password wrong in a password-protected share. Access to the nats storage is a bit difficult in order to check what's stored and for how long.
1.
2.
3.

Expected behavior

Obsolete data should be cleaned up one way or another.

The TTL could be the double of the configured time gap for the brute force protection (2 * STORAGE_PUBLICLINK_BRUTEFORCE_TIMEGAP, so 2 hours by default). It is expected that the TTL is refreshed on every change.

Actual behavior

Obsolete data is cleaned up only on access. If there is no access, the data will remain forever.

Setup

Please describe how you started the server and provide a list of relevant environment variables or configuration files.

Details

OCIS_XXX=somevalue
OCIS_YYY=somevalue
PROXY_XXX=somevalue

Additional context

The data we're storing is a list of IDs + timestamp as JSON string. Per share. (Data might change in the future if additional info is required)
Up to 5 items per share by default, although it's configurable and it might grow up to 100 (there is no real limit, but more than 100 failures per share seems too permissive).

[jvillafanez]

Planned patch below:

diff --git a/pkg/auth/manager/publicshares/publicshares.go b/pkg/auth/manager/publicshares/publicshares.go
index e28fc869f..f1ac853ff 100644
--- a/pkg/auth/manager/publicshares/publicshares.go
+++ b/pkg/auth/manager/publicshares/publicshares.go
@@ -80,6 +80,7 @@ func New(m map[string]interface{}) (auth.Manager, error) {
 
        revaStore := store.Create(
                store.Store(mgr.c.StoreType),
+               store.TTL(2*mgr.c.BruteForceTimeGap),
                microstore.Nodes(mgr.c.StoreNodes...),
                microstore.Database(mgr.c.StoreDatabase),
                microstore.Table(mgr.c.StoreTable),

However, it has some problems with nats-js-kv:

• For nats-js-kv (which is the default store we're using), we only can set the TTL for the whole bucket, not per key.
  • Per-key TTL might be possible with nats-js-kv, but it will require changes in the go-micro layer regarding the nats configuration. This is not supported at the moment.
  • The feature should have its own bucket / database, but since the name is configurable, we can't guarantee this.
• The TTL is applied on the bucket creation. Changing the TTL later in the configuration won't do anything.
  • Deleting the bucket might be an option (we store temporary data there, so it shouldn't be a problem), but all the storage-publicklink service replicas MUST be restarted in order to ensure the configuration is applied and the bucket is created.
  • Changing the TTL of the bucket might be possible, but the operation doesn't seems available from go-micro and we might need direct access to nats.

The behavior above might be different with other stores, which is undesired.