adobe / adobe-fetch Goto Github PK

When using readFileSync to read a private key, we get the following error:

Error while getting a new access token. TypeError [ERR_INVALID_ARG_TYPE]: The "key" argument must be one of type string, Buffer, TypedArray, DataView, or KeyObject. Received type object
    at prepareAsymmetricKey (internal/crypto/keys.js:267:13)
    at preparePrivateKey (internal/crypto/keys.js:285:10)
    at Sign.sign (internal/crypto/sig.js:80:46)

This is because we use 'merge' to copy the options which turns the buffer into an object.

See docs here for information:
https://adobe-apiplatform.github.io/umapi-documentation/en/api/ActionsRef.html#actionThrottle
and this is a Python example:
https://adobe-apiplatform.github.io/umapi-documentation/en/samples/index.html#retrying-requests

Requirements:

• Exponential Back-off with random delay
• Configurable max. number of retries / max. delay

Does this library work in the browser? I notice the use of node-persist which implies probably not. Can you clarify? Thanks :)

Add Travis CI and CodeCov to this repo

Currently we automatically adds x-api-key, x-request-id and x-gw-ims-org-id headers.

We would like to be able to configure all predefined headers. Preconfigured headers will be automatically added to every request made by adobe-fetch.

If the request already contains the header, it will take priority over the preconfigured header.

Note HTTP headers are case insensitive.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet.
We recommend using:

• CircleCI
• Travis CI
• Buildkite
• CodeShip
• Azure Pipelines
• TeamCity
• Buddy
• AppVeyor
  But Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

Currently the package uses node-persist to persist the token cache.

Allow developers to integrate with their own storage by providing get & set hooks.

Expected Behaviour

Calls to https://platform.adobe.io/data/privacy/gdpr should return a set of jobs

 jobs:
   [{jobId: 'xxxx-xxxx-xxxx-xxxx-xxxx', statusCode: 4},
     {jobId: 'yyyy-yyyy-yyyy-yyyy-yyyy', statusCode: 4}]

Actual Behaviour

Calls to https://platform.adobe.io/data/privacy/gdpr fail with:

{
    "errors": {
        "errorCode": 401,
        "title": "Invalid Token",
        "detail": "Expecting bearer token with this request",
        "errorType": "uri=/data/privacy/gdpr"
    },
    "totalRecords": 0
}

Reproduce Scenario (including but not limited to)

Steps to Reproduce

Platform and Version

$ node --version                                                                                                                                                                
v10.15.0

Sample Code that illustrates the problem

Running this code:

(async () => {
    const adobeFetch = require('@adobe/fetch').config({auth:{
        clientId: 'foo',
        clientSecret: 'foo',
        technicalAccountId: 'foo',
        orgId: 'foo',
        privateKey: 'foo',
        metaScopes: ['ent_gdpr_sdk']
    }});
   const response = await adobeFetch('https://platform.adobe.io/data/privacy/gdpr');
   console.log(await response.json());
})()

Results in:

{ errors:
   { errorCode: 401,
     title: 'Invalid Token',
     detail: 'Expecting bearer token with this request',
     errorType: 'uri=/data/privacy/gdpr' },
  totalRecords: 0 }

Logs taken while reproducing problem

Allow overriding of the x-api-key header to use the same token across multiple services.

Add support and tests for using Headers object. Currently we are only supporting a headers json.

☝️ Important announcement: Greenkeeper will be saying goodbye 👋 and passing the torch to Snyk on June 3rd, 2020! Find out how to migrate to Snyk and more at greenkeeper.io

The devDependency prettier was updated from 2.0.3 to 2.0.4.

🚨 View failing branch.

This version is covered by your current version range and after updating it in your project the build failed.

prettier is a devDependency of this project. It might not break your production code or affect downstream projects, but probably breaks your build or test tools, which may prevent deploying or publishing.

Your Greenkeeper Bot 🌴

Automatically generate x-request-id header.

Requirements:

• Generates a random GUID and send it as the x-request-id header.
• Use UUID v4 (Random)
• No longer than 30 characters
• Developers can provide their own x-request-id which will override the default one.
• Use debug to log x-request-id.

Support use in a browser environment.

Requirements:

• adobe/fetch should run in modern browser supporting the Fetch API (Polyfill will not be provided - Should be setup by the end developer).
• When running in a browser, the access token will be acquired by the end developer, not by adobe/fetch. This is because we do not want to expose a private key in a browser. The developer will provide an async function which will fetch the access token from a server or a serverless function.
• Use local storage instead of node-persist

Encrypt persisted token for added security.