Code Monkey home page Code Monkey logo

node-sdk-core's Introduction

Build Status npm-version semantic-release CLA assistant

IBM Node.js SDK Core

This project contains core functionality required by Node.js code generated by the IBM Cloud OpenAPI SDK Generator (openapi-sdkgen).

Installation

`npm install ibm-cloud-sdk-core`

Prerequisites

  • Node.js version 14 or newer
  • Note that v14 is technically supported but not officially guaranteed as we only test on v16 and higher

Usage

This package exports a single object containing a number of modules as top level properties.

Example:

// this is TypeScript, since the `openapi-sdkgen` project generates TypeScript
import { BaseService } from 'ibm-cloud-sdk-core';

class YourSDK extends BaseService { ... }

Authentication

The node-sdk-core project supports the following types of authentication:

  • Basic Authentication
  • Bearer Token Authentication
  • Identity and Access Management (IAM) Authentication
  • Container Authentication
  • VPC Instance Authentication
  • Cloud Pak for Data Authentication
  • No Authentication (for testing)

There are two ways to create an authenticator:

  1. Creating an instance and providing credentials programmatically
  2. Using the getAuthenticatorFromEnvironment function to create an authenticator from externally-provided configuration

For more information about the various authentication types and how to use them with your services, click here.

Examples

Programmatic

import { IamAuthenticator } from 'ibm-cloud-sdk-core';

const authenticator = new IamAuthenticator({
  apikey: '{apikey}',
});

External configuration

import { getAuthenticatorFromEnvironment } from 'ibm-cloud-sdk-core';

// env vars
// MY_SERVICE_AUTH_TYPE=iam
// MY_SERVICE_APIKEY=<apikey>
const iamAuthenticator = getAuthenticatorFromEnvironment('my-service');

Logging

This package uses debug for logging.

  • Logging is disabled by default.
  • Logging has been configured to use log levels which are assumed to be numerically ascending from most important to least important.
  • In order to see the log output, set the environment variable DEBUG including the desired log level.
    • DEBUG=ibm-cloud-sdk-core:error enables error logs
    • DEBUG=ibm-cloud-sdk-core:warning enables warning logs and below
    • DEBUG=ibm-cloud-sdk-core:info enables info logs and below
    • DEBUG=ibm-cloud-sdk-core:verbose enables verbose logs and below
    • DEBUG=ibm-cloud-sdk-core:debug enables debug logs and below

To see the output from all of the debugging levels you can use:

DEBUG=ibm-cloud-sdk-core*

The debug logger can be configured to be used for more than one library. In example, you can set a comma-separated string:

DEBUG=ibm-cloud-sdk-core:debug,other-lib:debug

Cookie Jar Support

By default, cookies are not supported in the SDK requests. If your SDK would benefit from this functionality, simply edit your code to instantiate a cookie jar (or instruct your users to do so) and pass it in the object containing configuration options to the BaseService class, as shown below. If the Boolean value true is given for the jar field, the SDK core will create a default instance of a Tough Cookie.

import tough = require('tough-cookie');

class MyClass extends BaseService {
  constructor(options: MyOptions) {
    // pass the cookie jar object or simply pass the value `true`
    // and a tough-cookie instance will be created by default
    options.jar = new tough.CookieJar();
    super(options);
  }
}

Issues

If you encounter an issue with this project, you are welcome to submit a bug report. Before opening a new issue, please search for similar issues. It's possible that someone has already reported it.

Tests

Run all test suites:

npm test

Contributing

See CONTRIBUTING.

License

This library is licensed under Apache 2.0. Full license text is available in LICENSE.

node-sdk-core's People

Contributors

ajhynes7 avatar alexpls avatar apaparazzi0329 avatar barrett-schonefeld avatar bessbd avatar carstenleue avatar dependabot[bot] avatar dpopp07 avatar eyeballin avatar germanattanasio avatar jorge-ibm avatar masterodin avatar mediumtaj avatar mgrattray avatar mojito317 avatar padamstx avatar pyrooka avatar ricellis avatar rmkeezer avatar saltedcaramelcoffee avatar semantic-release-bot avatar vmatyusgithub avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

node-sdk-core's Issues

move some dependencies to devdependencies

Although this is not a big deal , there are a few packages currently reported as dependency, that rather should be dev dependencies as they are mostly used during build phase and not at run time

"dependencies": {
    "@types/debug": "^4.1.12",
    "@types/file-type": "~5.2.1",
    "@types/isstream": "^0.1.0",
    "@types/node": "~10.14.19",
    "@types/tough-cookie": "^4.0.0",
    "expect": "^26.1.0"
  },

thanks

Consider splitting off tests/utils into own package

In v2.0.1, when the tests were converted to typescript, ts-jest was also introduced as a dependency. However, now, when installing this package (or more likely ibm-watson) will show the following error message:

$ npm install
npm WARN [email protected] requires a peer of jest@>=24 <25 but none is installed. You must install peer dependencies yourself.

which can be confusing / annoying to end-users to see.

Given that the test utilities exists to provide functionality to downstream modules, and not even to the node-sdk-core itself, it may be good to split it apart into its own publish package which those downstream consumers can still import it as necessary for their testing, but it does not get dragged into production code of external users.

upgrade axios-cookiejar-support to support axios 1.0

in your package json you are using axios-cookiejar-support ^1.0.0

this version is already at 4.0.3 https://github.com/IBM/node-sdk-core/blob/main/package.json

today axios itself upgraded to version 1 https://github.com/axios/axios/releases/tag/v1.0.0

and when using axios v1, node_sdk is no longer working

example of an error

Cannot find module 'axios/lib/defaults' from 'node_modules/axios-cookiejar-support/lib/index.js'

Require stack:
      node_modules/axios-cookiejar-support/lib/index.js
      node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/jwt-token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/iam-request-based-token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/iam-token-manager.js
      node_modules/ibm-cloud-sdk-core/auth/token-managers/index.js
      node_modules/ibm-cloud-sdk-core/auth/authenticators/cloud-pak-for-data-authenticator.js
      node_modules/ibm-cloud-sdk-core/auth/authenticators/index.js
      node_modules/ibm-cloud-sdk-core/auth/index.js
      node_modules/ibm-cloud-sdk-core/lib/base-service.js
      node_modules/ibm-cloud-sdk-core/index.js
      node_modules/@ibm-cloud/cloudant/cloudant/v1.js
      node_modules/@ibm-cloud/cloudant/index.js

ps i might need to check with that library if it's also compatible with axios 1.0

thanks

is it possible to make the library compatible with axios 1.0 and the latest version of axios-cookiejar-support

thanks

Authenticator returns `Promise<void | Error>`

The authenticator interface has the following syntax:

public authenticate(requestOptions: AuthenticateOptions): Promise<void | Error>

https://github.com/IBM/node-sdk-core/blob/main/auth/authenticators/authenticator.ts

Normally a Promise handles errors via its exception channel and regular values via its data channel. The type parameter identifies the data channel, promises do not have a way to specify the type of the exceptional channel.

Is it indeed intended to pass an error on the data channel? If so, why?
If not, the signature should be:

public authenticate(requestOptions: AuthenticateOptions): Promise<void>

EPROTO 140502679459712:error:1408F10B:SSL routines:ssl3_get_record:wrong version number- Response not received - no connection was made to the service.

Hi,

we have done the migration of Watson service and the consequent update of the library ibm-watson.

After the update our script doesn't work properly and returns the following error:

{ Error: write EPROTO 140502679459712:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:252:

at RequestWrapper.formatError (/home/Mauden01/workspace/script_upload/upload_doc_js/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:208:21)
at /home/Mauden01/workspace/script_upload/upload_doc_js/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:196:25
at process._tickCallback (internal/process/next_tick.js:68:7)

message:
'write EPROTO 140502679459712:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:../deps/openssl/openssl/ssl/record/ssl3_record.c:252:\n',
statusText: 'EPROTO',
body:
'Response not received - no connection was made to the service.' }

To understand if the problem was inherent with the environment, we have tried the following simple code, but returns the same error:

var DiscoveryV1 = require('ibm-watson/discovery/v1');
const { IamAuthenticator } = require('ibm-watson/auth');

const discovery = new DiscoveryV1({
    version: '2019-04-30',
    authenticator: new IamAuthenticator({
        apikey: '*************',
    }),
    url: '*************'
});

discovery.getCollection({
    environmentId: "********",
    collectionId: "********",
}).then(collection => {
    console.log('collection', collection)
}).catch(err => {
    console.log('---------------- ERROR GETCOLLECTION:', err)
})

We have tried the same code in local and works properly.

Another test done consists in the use of request library on the VM. Following the code:

const request = require('request');

var env = "********";
var col = "********";
var document_id = "1234"

request.get(`https://gateway-fra.watsonplatform.net/discovery/api/v1/environments/${env}/collections/${col}/documents/${document_id}`, {
    qs: {
        version: '2019-04-30'
    },
    auth: {
        user: 'apikey',
        pass: '************',
        sendImmediately: false
    },
    json: true
}, function (err, data) {
    if(err){
        console.log('err', err)
    }else{
        console.log('data',data)
    }
});

We have done the same test with Axios library and it works properly on the VM:

const axios = require("axios")

var environment_id = "**********";
var collection_id = "***********";
const {
    IamAuthenticator
} = require('ibm-watson/auth');

async function run() {
    try {
        let response = await axios({
            url: `https://gateway-fra.watsonplatform.net/discovery/api/v1/enviro                                                                                                                                                                                                nments/${environment_id}/collections/${collection_id}?version=2019-04-30`,
            auth: {
                username: 'apikey',
                password: '************'
            },
        })
        console.log(response.data);
    } catch (e) {
        console.log(e.message)
    }
}

run()

Request and Axios library work properly on the VM.
So from this tests, we think that the problem is between the setting on the VM and the ibm-watson library.

Following some info of the VM where we run the code:

cat /etc/os-release
NAME="CentOS Linux"
VERSION="7 (Core)"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="7"
PRETTY_NAME="CentOS Linux 7 (Core)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:7"
HOME_URL="https://www.centos.org/"
BUG_REPORT_URL="https://bugs.centos.org/"
CENTOS_MANTISBT_PROJECT="CentOS-7"
CENTOS_MANTISBT_PROJECT_VERSION="7"
REDHAT_SUPPORT_PRODUCT="centos"
REDHAT_SUPPORT_PRODUCT_VERSION="7"

node -v
v10.2.0

npm --versions
{ upload_doc_js: '1.0.0',
npm: '5.6.0',
ares: '1.14.0',
cldr: '33.0',
http_parser: '2.8.0',
icu: '61.1',
modules: '64',
napi: '3',
nghttp2: '1.29.0',
node: '10.2.0',
openssl: '1.1.0h',
tz: '2018c',
unicode: '10.0',
uv: '1.20.3',
v8: '6.6.346.32-node.8',
zlib: '1.2.11' }

openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017

echo "$http_proxy"
http://proxy.online.***.net:8080/

echo "$https_proxy"
http://proxy.online.***.net:8080/

Thanks

Latest version creates runtime error when bundled: `Class constructor BaseService cannot be invoked without 'new'`

Since this issue was originally found when referencing ibm-watson package, the ticket was originally created there. It appears to be an issue derived from referencing the node-cloud-sdk-core package. The last version of the ibm-cloud-sdk-core that is able to be bundled is 2.17.0. The details to reproduce the issue are contained in the ticket below:

watson-developer-cloud/node-sdk#1119

Axios 0.18.0 Vulnerabilties

The Node-RED Watson nodes which depend on IBM-Watson, and in turn node-sdk-core are no-longer deploying in IBM Cloud due to a vulnerability in Axios 0.18.0.

The current release of node-sdk-core has a dependancy to Axios at 0.18.0

The dependancy in node-sdk-core needs to be bumped to remove this vulnerability.

hit UnhandledPromiseRejectionWarning when using this module with `https://github.com/IBM/cloudant-node-sdk`

I'm working on change cloudant module to https://github.com/IBM/cloudant-node-sdk, and for authentication purpose, I'm using

const { CloudantV1 } = require('@ibm-cloud/cloudant');
const { IamAuthenticator } = require('ibm-cloud-sdk-core');
cloudantDB = CloudantV1.newInstance({
	authenticator: authenticator,
	httpsAgent: keepAliveAgent,
	serviceName: cloudantIamClientId || "pipeline-ui",
	serviceUrl: config.cloudantUrl
});

when I testing my code locally, I hit the following UnhandledPromiseRejectionWarning, do I need to be worried?

image

The automated release is failing 🚨

🚨 The automated release from the master branch failed. 🚨

I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.

You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.

Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.

Once all the errors are resolved, semantic-release will release your package the next time you push a commit to the master branch. You can also manually restart the failed CI job that runs semantic-release.

If you are not sure how to resolve this, here is some links that can help you:

If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.


Invalid npm token.

The npm token configured in the NPM_TOKEN environment variable must be a valid token allowing to publish to the registry https://registry.npmjs.org/.

If you are using Two-Factor Authentication, make configure the auth-only level is supported. semantic-release cannot publish with the default auth-and-writes level.

Please make sure to set the NPM_TOKEN environment variable in your CI with the exact value of the npm token.


Good luck with your project ✨

Your semantic-release bot 📦🚀

Bug in DEBUG ?

when i add my process.env.DEBUG variable to "ibm-cloud-sdk-core:info" i not only get the info items i also get an ERROR log , while this is not an error

"@ibm-cloud/cloudant": "^0.0.21",
"typescript": "^4.5.2",
"webpack": "^5.64.3",

node v16.13.0

  ibm-cloud-sdk-core:info Credential file does not exist. Will not be used +0ms
  ibm-cloud-sdk-core:info Credential file does not exist. Will not be used +2ms
  ibm-cloud-sdk-core:info Credential file does not exist. Will not be used +3ms
  ibm-cloud-sdk-core:error {
  ibm-cloud-sdk-core:error   status: 200,
  ibm-cloud-sdk-core:error   statusText: 'OK',
  ibm-cloud-sdk-core:error   headers: {
  ibm-cloud-sdk-core:error     'cache-control': 'must-revalidate',
  ibm-cloud-sdk-core:error     connection: 'close',
  ibm-cloud-sdk-core:error     'content-length': '208',
  ibm-cloud-sdk-core:error     'content-type': 'application/json',
  ibm-cloud-sdk-core:error     date: 'Wed, 24 Nov 2021 20:29:36 GMT',
  ibm-cloud-sdk-core:error     server: 'CouchDB/2.3.1 (Erlang OTP/19)',
  ibm-cloud-sdk-core:error     'x-couch-request-id': 'a94debd32c',
  ibm-cloud-sdk-core:error     'x-couchdb-body-time': '0'
  ibm-cloud-sdk-core:error   },
....
ibm-cloud-sdk-core:error   data: {
  ibm-cloud-sdk-core:error     couchdb: 'Welcome',
  ibm-cloud-sdk-core:error     version: '2.3.1',
  ibm-cloud-sdk-core:error     git_sha: 'c298091a4',
  ibm-cloud-sdk-core:error     uuid: '3fd2dc04a0c4b62f04ff84157d3bca8d',
  ibm-cloud-sdk-core:error     features: [ 'pluggable-storage-engines', 'scheduler' ],
  ibm-cloud-sdk-core:error     vendor: { name: 'The Apache Software Foundation' }
  ibm-cloud-sdk-core:error   }
  ibm-cloud-sdk-core:error } +0ms
$cloudant (constructor): Initialisation done - {"couchdb":"Welcome","version":"2.3.1","git_sha":"c298091a4","uuid":"3fd2dc04a0c4b62f04ff84157d3bca8d","features":["pluggable-storage-engines","scheduler"],"vendor":{"name":"The Apache Software Foundation"}}

thanks

There is an issue on last push made on request-wrapper

There seems to be an issue on the request-wrapper file which has been modified just few hours back.

Due to this other package(ibm-watson) which is using this package on version 2.4.3 is having error as follows:

Bad Request: Missing 'version' query parameter
at RequestWrapper.formatError (/home/masteradmin/lucy-latest/Lucy-Next-Application/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:223:21)
at /home/masteradmin/lucy-latest/Lucy-Next-Application/node_modules/ibm-cloud-sdk-core/lib/request-wrapper.js:211:25
at Immediate. (/home/masteradmin/lucy-latest/Lucy-Next-Application/node_modules/es6-shim/es6-shim.js:1382:26)
at processImmediate (internal/timers.js:456:21)
at process.topLevelDomainCallback (domain.js:137:15) {
statusText: 'Bad Request',

This is error from Watson assistant as its APIs require version as its query string but its not being sent via this package.

I think issue is that query parameter is not being sent correctly due to these changes because of which all packages using 2.4.3 version of this package and hitting this function is unable to send query parameters as part of the request.

It works fine on previous version of the same package which is before last merge. Issue is on request-wrapper file and clearly requests are not able to send the query parameters.

Error: EISDIR: illegal operation on a directory

Hello,
when releasing our Application from Azure DevOps, we encounter this error:

2022-06-17T12:23:12.2811600Z Copying file: 'node_modules/ibm-cloud-sdk-core/ibm-cloud-sdk-core.d.ts'
2022-06-17T12:23:12.2815569Z Error: EISDIR: illegal operation on a directory, open '/home/site/wwwroot/node_modules/ibm-cloud-sdk-core/docs'

We noticed that this error started popping up with the latest releases of your package. And specifically because the /docs directory is now appearing as a file.

Screen Shot 2022-06-21 at 15 45 04

We mitigated it, by downgrading to version: 2.17.10 which the error doesn't appear.

Do you have any solutions for that issue apart from downgrading? Is this error planned to be fixed at a later release?

Thank you in advance.

high severity in jsonwebtoken <=8.5.1

i got this warning this morning

thanks

# npm audit report

jsonwebtoken  <=8.5.1
Severity: high
jsonwebtoken's insecure implementation of key retrieval function could lead to Forgeable Public/Private Tokens from RSA to HMAC - https://github.com/advisories/GHSA-hjrf-2m68-5959
jsonwebtoken vulnerable to signature validation bypass due to insecure default algorithm in jwt.verify() - https://github.com/advisories/GHSA-qwph-4952-7xr6
jsonwebtoken unrestricted key type could lead to legacy keys usage  - https://github.com/advisories/GHSA-8cf7-32gw-wr33
jsonwebtoken has insecure input validation in jwt.verify function - https://github.com/advisories/GHSA-27h2-hvpr-p74q
No fix available
node_modules/ibm-cloud-sdk-core/node_modules/jsonwebtoken
  ibm-cloud-sdk-core  >=0.3.0
  Depends on vulnerable versions of jsonwebtoken
  node_modules/ibm-cloud-sdk-core
    @ibm-cloud/cloudant  *
    Depends on vulnerable versions of ibm-cloud-sdk-core
    node_modules/@ibm-cloud/cloudant

Older version libraries coming as dependency

  • Steps to reproduce
    Add [email protected] library to package.json, it will add [email protected] as dependency. In return [email protected] is adding [email protected] instead of latest. And this version is having a dependency on yargs-parser. Which is failing for contrast.
  • Expected behavior
    The application should run with contrast but its failing when contrast is enabled. As yargs-parser referred is older version and creating problems.
  • Actual behavior
    Contrast enabled server fail to start and gives a message.
    "ERR npm WARN [email protected] requires a peer of jest@>=24 <25 but none is installed. You must install peer dependencies yourself."
  • Node version
    10.16.3
  • SDK version
    IBM SDK for Node.js Buildpack v4.3-20200606-1928

When you open an issue for a feature request, please add as much detail as possible:

  • A descriptive title starting with the service name
    [email protected]
    SDK for Node.js
    umanam
    umanam
    23 Jun 2020 (an hour ago)

I'm using [email protected] and it is using [email protected]. This is using ts-jest as dependency and loading older version [email protected]. There is the problem and its failing in contrast build.

I get error "ERR npm WARN [email protected] requires a peer of jest@>=24 <25 but none is installed. You must install peer dependencies yourself." while deploying application, even fixing with these suggestion its not helping. At the end its conflicting on version of yargs-parser library referenced in ts-jest. Please fix the issue with ibm-cloud-sdk-core package.json, so that it loads correct version of dependencies.

  • A description of the problem you're trying to solve
    We want to enable fetch of latest ts-jest library with latest [email protected].
    Testing --- Repackage library ibm-cloud-sdk-core and invoke in a project then try if its pulling latest ts-jest or not.
  • A suggested solution if possible

cannot receive response from IBM watson: Body of error is HTTP ClientRequest

Hello! I didn't see an issue related to my problem, so I'll go ahead and tell the problem I am facing. Currently, the app we are using to connect to the watson assistance is behind a DMZ, so, only selected ports are opened, in the case of watson we are using the port 443. The problem is we somehow can't receive the answer after the message has been sent. Here's what the app says when I want to send a message:

68957529-fdab8d00-07a8-11ea-9b15-cb03815a27d2
68973785-edf26f80-07cd-11ea-899c-1f572de656b6

I wonder if it is related to that port not being opened?

CVE-2023-45857 on the axios module used in the package

We are seeing a CVE on the module.
The CVE is: CVE-2023-45857

Vulnerability scan summary for package-lock.json
	# of Packages scanned: 561
	# of Vulnerabilities found: 1
	Vulnerability found: Cross-site Request Forgery (CSRF) - SNYK-JS-AXIOS-6032459
		URL: https://security.snyk.io/vuln/SNYK-JS-AXIOS-6032459
		Package: axios
		Version: 1.4.0
		Introduced By: ibm-cloud-sdk-core:4.1.2 --> axios:1.4.0
		Severity: high
		Description: axios is a promise-based HTTP client for the browser and Node.js.
			
			Affected versions of this package are vulnerable to Cross-site Request Forgery (CSRF) due to inserting the X-XSRF-TOKEN header using the secret XSRF-TOKEN cookie value in all requests to any server when the XSRF-TOKEN0 cookie is available, and the withCredentials setting is turned on. If a malicious user manages to obtain this value, it can potentially lead to the XSRF defence mechanism bypass.
		Updated at: 2023-10-25T07:24:40.920085Z
		Codes: [CVE-2023-45857]

CVE-2022-25883 on the semver module used in the package

We are seeing a CVE on the module.
The CVE is: CVE-2022-25883

	Vulnerability found: Regular Expression Denial of Service (ReDoS) - SNYK-JS-SEMVER-3247795
		URL: https://security.snyk.io/vuln/SNYK-JS-SEMVER-3247795
		Package: semver
		Version: 6.3.0
		Introduced By: ibm-cloud-sdk-core:4.0.8 --> semver:6.3.0
		Severity: medium
		Description: semver is a semantic version parser used by npm.
			
			Affected versions of this package are vulnerable to Regular Expression Denial of Service (ReDoS) via the function new Range, when untrusted user data is provided as a range.
		Remediation: 7.5.2
		Updated at: 2023-06-20T15:39:58.315102Z
		Codes: [CVE-2022-25883]

Vulnerability: ibm-cloud-sdk-core is using a vulnerable version of jsonwebtoken

jsonwebtoken package version needs to be updated

  └─┬ [email protected]
    └── [email protected]

┌───────────────┬──────────────────────────────────────────────────────────────┐
│ Moderate      │ jsonwebtoken vulnerable to signature validation bypass due   │
│               │ to insecure default algorithm in jwt.verify()                │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ jsonwebtoken                                                 │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Patched in    │ >=9.0.0                                                      │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ c71d4fb387532698c547b72cd9ce7d3dc531c3c534cbbe2fb15b011aafa… │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ c71d4fb387532698c547b72cd9ce7d3dc531c3c534cbbe2fb15b011aafa… │
│               │ > ibm-cloud-sdk-core > jsonwebtoken                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://github.com/advisories/GHSA-qwph-4952-7xr6            │
└───────────────┴──────────────────────────────────────────────────────────────┘

Update axios version to 0.25.0

  • We have identified a security vulnerability in the route that ends with ibm-cloud-sdk-core>axios>follow-redirects for follow-redirects version 1.14.6.
  • Same has been resolved in follow-redirects version 1.14.7 which is consumed by axios version 0.25.0
  • ibm-cloud-sdk-core is currently using axios version 0.21.4 (https://github.com/IBM/node-sdk-core/blob/main/package.json#L81)

Upgrading to axios version 0.25.0 will help us to resolve this vulnerability.

Missing @types/debug into package.json (devDependencies)

Error Description:

Library debug is specified into dependencies, but related @types/debug is missing.
Transpiler produces the following error at build time:

node_modules/ibm-cloud-sdk-core/es/lib/get-new-logger.d.ts:16:26 - error TS7016: Could not find a declaration file for module 'debug'. '/node_modules/debug/src/index.js' implicitly has an 'any' type.
  Try `npm i --save-dev @types/debug` if it exists or add a new declaration (.d.ts) file containing `declare module 'debug';`
16 import { Debugger } from 'debug';

Solution:

Add "@types/debug": "^4.1.12" into devDependencies

"debug": "^4.1.1",

Workaround (Tested):

Add explicit "@types/debug": "^4.1.12" into the main project, in addition to "node-sdk-core".

Thanks

SDK pulls in development level dependencies for production

This SDK is used by several other IBM cloud SDKs, in my case the @ibm-cloud/secrets-manager SDK. My application is a consumer of the @ibm-cloud/secrets-manager and I would like to package it (and its dependencies) as part of my app.

I notice that this causes a significant amount dependencies to be pulled in that are not required for production and that should also not appear in the dependencies of a production level application, e.g. the expect package. This package is meant to write unit tests and should only be a development level dependency. It alone adds around 200KB to the overall bundle size, because it in turn depends on jest packages which should not exist in a production environment either (see https://bundlephobia.com/package/[email protected])

The reason for this dependency is the fact that this core SDK exports utility functions for testing purposes as part of its regular index (https://github.com/IBM/node-sdk-core/blob/main/index.ts#L21)
Since this SDK is also only available as a commonjs package, there is also no way to use tree shaking to get rid of these undesirable and unused dependencies.

I suggest to move the test functions to a sub-package with its own package.json and its own dependencies. This way consuming SDKs can still make use of the exported test helpers but they would not interfer with the production usage of the package.

Besides the undesirable bundle size this also effects legal clearance when we at IBM depend on the SDK, because test level packages typically do not have to be cleared with the same diligence as production level packages. With the current design, we are forced to clear test packages.

Vulnerability in axios 0.21.1

Remember, an issue is not the place to ask questions. You can use
Stack Overflow for that, or
you may want to start a discussion on dW Answers.

Before you open an issue, please check if a similar issue already exists or has been closed before.

When reporting a bug, please be sure to include the following:

  • Steps to reproduce
  • Expected behavior
  • Actual behavior
  • Node version
  • SDK version:

When you open an issue for a feature request, please add as much detail as possible:

  • A descriptive title starting with the service name
  • A description of the problem you're trying to solve : dependency check was failed for old version of axios, see screenshot
  • A suggested solution if possible : upgrade to latest 0.21.3

image

VpcInstanceAuthenticator uses wrong version, no option to change it

Hi all, I'm using ibm-cloud-sdk-core (v4.0.2), when trying to authenticate with VpcInstanceAuthenticator, getting "Caught exception from VPC 'create_access_token' operation: The version value cannot be before 2022-03-01".

From debug I see that '2021-09-20' passed by default, I don't see any option to change it.

error TS2304: Cannot find name 'File'.

I faced an issue with the package when executed ts build:

C:\...\...\node_modules\typescript\bin\tsc
node_modules/ibm-cloud-sdk-core/lib/content-type.d.ts:4:35 - error TS2304: Cannot find name 'File'.

4     fromFilename: (file: String | File | ReadableStream | Buffer | FileObject) => string;
                                    ~~~~

node_modules/ibm-cloud-sdk-core/lib/content-type.d.ts:4:42 - error TS2304: Cannot find name 'ReadableStream'.

4     fromFilename: (file: String | File | ReadableStream | Buffer | FileObject) => string;
                                           ~~~~~~~~~~~~~~

SDK is not tree shakeable

When bundling node applications is it desirable to keep the overall bundle size small, even if the application is only used on the server side. One state of the art mechanism to achieve this is tree shaking, e.g. via webpack.

Tree shaking however only works with ES6 style modules, not with commonjs style modules. Libraries that support tree shaking expose multiple entry points via the package.json, one for commonjs (main) and one for es6 style modules (module).

Since the SDK is based on TS, transpiled to JS, this is very easy to achieve by adding two compile steps. One for JS (the current one) and one for ES6 based on a derived tsconfig.json, e.g. such as this:

{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "target": "ES6",
        "module": "ESNext",
        "outDir": "./dist/es",
        "declaration": true
    }
}

This would help applications tremendously, getting the overall size down and would also avoid as a desirable side effect to exclude test level libraries from production bundles (since they would be tree shaken).

CIEBot applications failed to start with 'ERR_PACKAGE_PATH_NOT_EXPORTED' after upgrade to node-sdk-core to v4.1.4

Remember, an issue is not the place to ask questions. You can use
Stack Overflow for that, or
you may want to start a discussion on dW Answers.

Before you open an issue, please check if a similar issue already exists or has been closed before.

When reporting a bug, please be sure to include the following:

  • Steps to reproduce : change dependencies to "ibm-cloud-sdk-core": "^4.1.4", run npm update, run npm start
  • Expected behavior : app started
  • Actual behavior : app failed to start with below errors
Error [ERR_PACKAGE_PATH_NOT_EXPORTED]: Package subpath './lib/defaults' is not defined by "exports" in /Users/whitney/workspace/aria/gobot-commands-processor/node_modules/axios/package.json
   at new NodeError (node:internal/errors:405:5)
   at exportsNotFound (node:internal/modules/esm/resolve:362:10)
   at packageExportsResolve (node:internal/modules/esm/resolve:698:9)
   at resolveExports (node:internal/modules/cjs/loader:567:36)
   at Module._findPath (node:internal/modules/cjs/loader:636:31)
   at Module._resolveFilename (node:internal/modules/cjs/loader:1063:27)
   at Module._load (node:internal/modules/cjs/loader:922:27)
   at Module.require (node:internal/modules/cjs/loader:1143:19)
   at require (node:internal/modules/cjs/helpers:119:18)
   at Object.<anonymous> (/Users/whitney/workspace/aria/gobot-commands-processor/node_modules/axios-cookiejar-support/lib/index.js:8:40) {
 code: 'ERR_PACKAGE_PATH_NOT_EXPORTED'
}
  • Node version: 18.18.2
  • SDK version :4.1.4

When you open an issue for a feature request, please add as much detail as possible:

  • A descriptive title starting with the service name
  • A description of the problem you're trying to solve
  • A suggested solution if possible

Typescript Compilation: Cannot find name 'File'

Hi there

This is my first bug report / issue so apologies with any issues with it.

> [email protected] build
> tsc && cp package.json dist/

node_modules/ibm-cloud-sdk-core/es/lib/content-type.d.ts:4:35 - error TS2304: Cannot find name 'File'.

4     fromFilename: (file: String | File | Buffer | NodeJS.ReadableStream | FileObject) => string;
                                    ~~~~


Found 1 error.

Versions:

"typescript": "4.4.4"
"ibp-node-sdk": "^0.1.12"
"ibm-cloud-sdk-core": "2.17.10"

Node: v16.12.0

I'm building a library, that will eventually go into a server side application but the build is failing because of dependency on the DOM File type.

This was reported in #9, however only the readable stream was fixed and not File.

I'm not too sure what a possible fix could be, maybe an interface with just a subset of what's actually needed from File

Responses do not return properly downstream for (at least) STT and TTS

I upgraded some of my stuff from using the 1.0.0-rc4 to 1.0.0 and noticed that two of the endpoints I am using in the ibm-watson downstream package I was using for my work now no longer return properly, breaking things downstream. Rolling back to 1.0.0-rc4 gets them working again. I am running node 12.

My downstream proof-of-concept files:

index.js:

const TextToSpeechV1 = require('ibm-watson/text-to-speech/v1');
const SpeechToTextV1 = require('ibm-watson/speech-to-text/v1');

const tts = new TextToSpeechV1({});
const stt = new SpeechToTextV1({});

tts.listVoices({}).then((response) => {
  console.log('--got tts response--');
}).catch((err) => console.error(err));

stt.listModels({}).then((response) => {
  console.log('--got stt response--');
}).catch((err) => console.error(err));

running it:

$ npm list ibm-cloud-sdk-core
[email protected] /Users/mpeveler/work/cisl/poc
├── [email protected]
└─┬ [email protected]
  └── [email protected]  deduped
$ node index.js
$ npm install [email protected]
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

+ [email protected]
updated 59 packages and audited 832 packages in 5.191s
found 0 vulnerabilities
$ node index.js
--got stt response--
--got tts response--

When reporting a bug, please be sure to include the following:

  • Steps to reproduce
  • Expected behavior
  • Actual behavior
  • Node version
  • SDK version

When you open an issue for a feature request, please add as much detail as possible:

  • A descriptive title starting with the service name
  • A description of the problem you're trying to solve
  • A suggested solution if possible

Error after 4.0.1 release -JsonWebTokenError: secret or public key must be provided

Started getting this error after 4.0.1 was released. Error was not present with 4.0.0.
App has a direct dependency on latest @ibm-cloud/platform-services which has a dependency on this project.

Error: JsonWebTokenError: secret or public key must be provided
    at IamTokenManager.JwtTokenManager.saveTokenInfo (/app/node_modules/ibm-cloud-sdk-core/auth/token-managers/jwt-token-manager.js:111:19)
    at IamTokenManager.IamRequestBasedTokenManager.saveTokenInfo (/app/node_modules/ibm-cloud-sdk-core/auth/token-managers/iam-request-based-token-manager.js:137:40)
    at /app/node_modules/ibm-cloud-sdk-core/auth/token-managers/token-manager.js:109:19
    at runMicrotasks (<anonymous>)
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.