jonschlinkert / cache-base Goto Github PK

I think it would be nice to support adding default values that would work like this:

const CacheBase = require('cache-base');
const app = new CacheBase();

app.set('foo', 'xxx');
app.default('foo', 'one');
app.default('bar', 'two');
app.default('baz', 'three');
app.set('baz', 'zzz');

console.log(app.get('foo'));
//=> 'xxx'

console.log(app.get('bar'));
//=> 'two'

console.log(app.get('baz'));
//=> 'zzz'

console.log(app);
// Cache {
//   cache: { foo: 'xxx', bar: 'two', baz: 'zzz' },
//   defaults: { foo: 'one', bar: 'two', baz: 'three' } }

@doowb any thoughts?

Another issue, #5 describes a similar but different approach

According to https://app-eu.whitesourcesoftware.com/Wss/WSS.html#!securityVulnerability;id=CVE-2020-28275 there is a

Prototype pollution vulnerability in 'cache-base' versions 0.7.0 through 4.0.0 allows attacker to cause a denial of service and may lead to remote code execution.

in

There seems to be a CVE already assigned: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-28275

Any chance to get this fixed?

potentially use this as a base for config-cache. the only thing I'm having a hard time deciding on is whether or not to allow getting/setting of property paths, e.g.

get('data.foo.bar');
//=> '{foo: {bar: {...}}}'

This can be expensive, but I think if we prevent lookups when the key doesn't have a . it should speed things up. Also, I'm not currently doing any setting of object paths (set('a.b.c', {foo: 'bar'})), but it can be (re)implemented if it's necessary to use this for config-cache.

cc @doowb

I've never been a fan of settings values on the root, as it creates potential for conflicts, makes it harder to get the actually user-defined values, et cetera.

I think we should just set values on .cache by default, or a property specified by the user.

The consequence of this change is that you won't be able to directly get or set values from the root of the instance of cacheBase, you'd have to get and set on cacheBase.cache or whatever property was defined.

@doowb any thoughts? can you think of other side effects of removing support for getting/setting on the root of the object? will it materially change how we do things in other libs?

Hi,

Can't find support for TTL. Would be very usefull.

Thanks

Error log(cache-base version(4.0.0))::
Creating an optimized production build...
Failed to compile.

Failed to minify the code from this file:

    ./node_modules/cache-base/index.js:24

related to #2

Before was using has-value(s), now is just typeof val !== undefined

also add hasOwn and union methods?

Please update to set-value v3.0.1 to bring in the recent security patch.

Please tag version 0.8.4

#CVE-2021-23440: the cache-base library internally uses set-value, and set value version below 4.0.1 are vulnarable. is there any plan to fix this issue and release a new version.

It shows that default writing is to app.cache but it writes to app.
So, PR for fix or PR for module.exports = namespace('cache')?

Hello @jonschlinkert,

there is a security vulnerability in cache-base. Is it possible to fix that?!

Link: https://snyk.io/test/npm/cache-base/1

We have found vulnerability in unset-value, the cache-base library internally uses unset-value, and unset value version below 2.0.1 are vulnarable. is there any plan to fix this issue and release a new version.
Please refer
https://security.snyk.io/vuln/SNYK-JS-UNSETVALUE-2400660 @jonschlinkert

Consider allowing .get to return a default value.

app.get('foo', 'default-value');