Migration to Use New API Features

Description

Currently, the AttachmentProcessor works with reading from and writing to our steward service. In the longer term, there is a desire to migrate from Steward to Maester. Currently, when storing data in Maester, in general, client side encryption is used. As a result, if we simply swap out Steward URLs with Maester URLs (and the existing Maester encryption logic) then existing components which work with attachments would not be functional. We should add logic such that if the provided URL is a Maester URL, then attachment processor should read it seamlessly.

Due Date

None, but:

• It would be nice to deprecate Steward
• It would nice to be able to have all these changes implemented prior to doing rework on components that handle attachments
• In the future, we may start billing for Maester usage

Also makes sense to work in parallel on #41

Need to change private to protected access modifier for getValidToken and fetchNewToken methods in OAuth2RestClient class

In current implementation of jsonataTransform.ts script there's no way to avoid 'handlePassthrough' - adding all passthrough data to 'message.body.elasticio' variable. This approach should be changed

Other Feature Request

Description

Currently, a bunch of the logic to handle interactions with elastic.io's own REST API are contained within the two files platformApiLogicClient.js and platformApiRestClient.js within the ipaas-core-component. Ideally, we should migrate these files to this library so that this logic can be used for other purposes.

Other Feature Request

Description

[Description of the enhancement]

Definition of Done

[What you expected to be implemented]

Most of the functionality in the library isn't really documented.

There is a misprint in the description of the ApiKeyRestClient.

The example in the topic should be fixed:
https://github.com/elasticio/component-commons-library/blob/master/README.md#apikeyrestclient

Migration to Use New API Features

Description

Follow up to #42

The rollout strategy is as follows:

1. Apply #42 so that Maester attachments can be read along side Stewart attachments.
2. Migrate all components that use attachments to this version of the component commons
3. Apply this change so that Maester attachments are used by default.
4. Deprecate Stewart

After this change, only Maester attachments should be created with AttachmentProcessor.

We need to complete documentation for the library in order to comply DoD

The request package used by this library has been deprecated since Feb 2020. This library should be updated to use a fully maintained package for http request functionality.

Current implementations of getEndTime and getStartTime methods returns
cfg[END_TIME] || new Date(MAX_DATE)
which should new wrapped into new Date() one more time to be sure in Date object processing.
Also, need to add validation for possible Invalid Date value in case of incorrect input

Feature Request

Description

On our platform, we use version 1.7

In case the user tries to use the code that works for version 1.8.6 then our component(version 1.7) will return empty objects.

Intercome case

Definition of Done

Currently, there is the latest version of the library with the suffix dev.3 that should be removed.

https://www.npmjs.com/package/@elastic.io/component-commons-library

Additionally, there was found a potential security vulnerability in the lodash dependency:
https://github.com/elasticio/component-commons-library/network/alerts

Component Bug Report

Description

Method uploadAttachment in class AttachmentProcessor use maxContentLength to define max file size, but it limits only response, instead of it need to use maxBodyLength:

maxContentLength defines the max size of the http response content in bytes allowed in node.js
maxBodyLength (Node only option) defines the max size of the http request content in bytes allowed

Axios docs

Internal Issue/Enhancement

Description

Fix dev dependencies: move typescript and @types/node to devDependencies

Definition of Done

typescript and @types/node in devDependencies instead of main dependencies

elasticio/rest-api-component#111