v1.1.5 (2025-04-08) Security and Optimization for DebugAndLog and utils.sanitize()

• Polynomial regular expression used on uncontrolled data in utils.sanitize()
• Use of externally-controlled format string in DebugAndLog

Malformed strings could be passed to DebugAndLog and utils.sanitize() that could cause unexpected results.

utils.sanitize() will now only handle strings/stringified objects that are of a maximum length of 200,000 characters to prevent Denial of Service. As a result, objects or strings longer than the maximum length will be returned with the message: "Input exceeds maximum allowed length" rather than sanitized output. This will affect the logging of any objects or text strings that are longer than 200,000 characters when stringified.

utils.sanitize() is used by DebugAndLog when outputting log data that might contain sensitive information.

Some regular expressions take a long time to match certain input strings to the point where the time it takes to match a string of length n is proportional to nk or even 2n. Such regular expressions can negatively affect performance, or even allow a malicious user to perform a Denial of Service ("DoS") attack by crafting an expensive input string for the regular expression to match.

While DebugAndLog has also been optimized, there is no change to its results. Internally, it was enhanced to prevent malformed messages that are sent to it.

Functions like the Node.js standard library function util.format accept a format string that is used to format the remaining arguments by providing inline format specifiers. If the format string contains unsanitized input from an untrusted source, then that string may contain unexpected format specifiers that cause garbled output.

v1.1.4 APIRequest class now has additional X-Ray annotations

Check the CHANGELOG for additional information.

However, when utilizing the APIRequest class to call remote endpoints (and when AWS X-Ray is enabled for your Lambda function) additional data will be collected about the request under Annotations and Meta Data.

The trace will show up with the segment name APIRequest/example.com (where example.com is the host name you are accessing)

v1.1.3 connection.options fixed when passing to CacheableDataAccess.getData

Fix: The options property of connection was getting lost when passed to CacheableDataAccess.getData() due to an issue with the way the cache hash Id was calculated.

v1.1.2

Feature: Added new options to specify how duplicate parameters in a query string should be handled. This allows you to craft your query string to match what your endpoint expects when it parses the query string. See changelog or readme for more information.

v1.1.1 Minor fixes and updates

Just a few fixes and tweaks. One change is the way the cache hash id/key is generated. It used to use all properties of the connection such as host, pat, method, query-string parameters, etc. It also used options if it was sent. However, options does not affect the content, and when using dynamic timeouts, can change the hash id causing cache misses.
Options is now removed before calculating the cache id.

v1.1.0 First Minor Release!

There should be no breaking changes, but this is being released as a minor rather than a patch.

• Enhancement: Shared cache stores are readily available. You can share one DynamoDb table and one S3 bucket among your applications. As always, the data encryption key keeps your data secure. As an added feature, each Cache Id is hashed with the application name (Lambda function name) to keep the data separate among applications and instances. (There is currently no support for sharing cached data among different applications.)
• Feature: New Response and ClientRequest classes. In the past, you needed to extend the RequestDataModel and RequestInfo classes. While the RequestDataModel and RequestInfo classes are still available, they should help with organizing your application and logging. The ClientRequest class can handle incoming parameter validation and route parsing. The Response class can handle assembling the response and logging.
• Began restructuring of the library. No noticeable differences on the end user end, but this better organizes the underlying Classes and methods.

v1.0.39 X-Ray and Chai 5.x tests

3 of 3 new features added in April are now fully functional and documented. See documentation for AWS X-Ray and AWS Parameters and Secrets Lambda Extension.

The experimental feature tools.hashThisData() from v1.0.33 is still experimental and undocumented.

• Feature: Added AWS XRay to HTTP, SSM, S3, and DynamoDb requests. Add Lambda environment variable CacheData_AWSXRayOn and set to true to enable. Check the X-Ray traces using CloudWatch.
• Feature: Added a switch for experimental tools.hashThisData(). Passing the useToolsHash: true property during Cache.init() will use the provided tools.hashThisData() function rather than the current hash object package. By default, it is false, and the current hash object function is used.
• Documentation: Added documentation for both X-Ray and CachedParameterSecret
• Chore: Updated tests so it would work with chai 5.x

v1.0.38 Added experimental Parameters and Secrets functionality to work with AWS Extension

This release has an experimental Classes to provide an option to use the AWS Parameters and Secrets Lambda Extension to access and cache AWS SSM Parameters and Secrets Manager secrets.

Documentation of use will come at a later date after the update proves stable.

v1.0.37 Bug fix for issue #109

v1.0.37b

updating version for release

v1.0.37 Bug fix for issue #109

fix: #109 Write to DynamoDb failed for id_hash Special numeric value …