All endpoints in the API server should be documented. This can be done in the https://github.com/cdnjs/static-website repo ready for when the new site & API are rolled out.

.ts, .wasm and .hpb have now been added to the Cf whitelist, so these should be added to fileMap.js so they can show on the site.

Help request

Problem

Hello guys, actually I ran into a strange behavior on the cdnjs api.
While trying to get the latest version of a library it seems that the response is not always the same when using the fields query param.
For example:
if you reach this endpoint several times:

https://api.cdnjs.com/libraries/typescript?fields=version,latest

the answer is randomly one of these two responses:
{"version":"4.7.4","latest":"https://cdnjs.cloudflare.com/ajax/libs/typescript/4.7.4/typescript.min.js"}
{"version":"4.8.0-beta","latest":"https://cdnjs.cloudflare.com/ajax/libs/typescript/4.8.0-beta/typescript.min.js"}
Only the second one should be expected

Nevertheless when trying to directly get the full response of a library without the fields query param:
https://api.cdnjs.com/libraries/typescript
the response is always constant and as expected:

{"name":"typescript","latest":"https://cdnjs.cloudflare.com/ajax/libs/typescript/4.8.0-beta/typescript.min.js","sri":"sha512-
...

Do you know where it can come from ?
Kr,

Jordan.

for example

https://cdnjs.com/libraries/antd
https://api.cdnjs.com/libraries/antd

for version 4.0.2 and 4.0.1, API list has extra files like antd.dark.less , which is 403

how to get real file list from API?

Feature request

Feature description

The feature that I am suggesting is the addition of an SRI validation endpoint to the CDNJS api. This endpoint would allow developers to verify the integrity of the third-party libraries in their web projects, ensuring that they have not been tampered with or modified during delivery.
Endpoint (since the SRI can contain a /):

/sri_lookup/:hash1
/sri_lookup/:hash1/
/sri_lookup/:hash1/:hash2
/sri_lookup/:hash1/:hash2/

How the feature is useful

The usefulness of this feature to users of the API is significant, as it provides an extra layer of security when using third-party libraries. Developers can use SRI to check if a library has been tampered with or modified, while saving 2-3 requests that would have been done to get the SRI.
My use example, is that I'm building a web app that scans modified library files for malicious code, and in order to mark is modified, the app tries to find the library associated to the file, by doing a few requests, then gets the version of the library found with the version mentioned in the file, then checks the hashes. By just sending the hash to the API and getting and yes or no, helps a bit.

EDIT: This is clearly a suggestion/improvement, not a bug. I can not attach a label, so I'm mentioning it here. :)

Feature request

Feature description

Single API URL for a chain of libraries.

The same feature is implemented in Google fonts as it is given below:

<link href="https://fonts.googleapis.com/css2?family=Recursive:wght@400;700&family=Roboto:wght@300;400&display=swap" rel="stylesheet">

This can be a similar format for cdnjs API.

<link href="https://api.cdnjs.com/libraries/[email protected]:bootstrap.min.css;[email protected]:photoswipe.min.css,default-skin/default-skin.min.css;" rel="preload" as="style" onload="this.onload=null;this.rel='stylesheet'">

<script src="https://api.cdnjs.com/libraries/[email protected]:jquery.min.js;[email protected]:photoswipe.min.js,photoswipe-ui-default.min.js;" defer type="text/javascript">

When this request is received by the API server, query is parsed to create a JSON object. Using this object, server will retrieve all the specific libraries requested and concatenate all of them in the same order as it is requested.

The only restriction is the CSS & JS can not be mixed up in same request as it can not be loaded by the same HTML tag. Also, Images cannot be requested in the same way. But map files can be requested in a similar way in future versions if really needed.

How the feature is useful

This could decrease the request count. When all libraries needed at loaded in a single request, there will not be any blocking requests and it increases the web performance of the website as part of optimization.

Help request

Problem

Highlight.js returning invalid JSON data. URL: https://api.cdnjs.com/libraries/highlight.js
Error:
SyntaxError: JSON.parse: unterminated string at line 1 column 2626990 of the JSON data

What I have tried

Tried using CURL to fetch with cache control set to no-cache and still returns the same invalid JSON.
curl -H 'Cache-Control: no-cache' https://api.cdnjs.com/libraries/highlight.js --trace-asci output.txt
output.txt

Vulnerabilities

DepShield reports that this application's usage of lodash:4.17.19 results in the following vulnerability(s):

• (CVSS 7.4) [CVE-2020-8203] Prototype pollution attack when using _.zipObjectDeep in lodash <= 4.17.15.

Occurrences

lodash:4.17.19 is a transitive dependency introduced by the following direct dependency(s):

• eslint:7.6.0
        └─ lodash:4.17.19
        └─ table:5.4.6
              └─ lodash:4.17.19

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Help request

Problem

scoped packages (e.g @angular/compiler) do not appear in search results and package info

What I have tried

https://api.cdnjs.com/libraries?search=@angular/compiler
https://api.cdnjs.com/libraries?search=%40angular%2Fcompiler
https://api.cdnjs.com/libraries/@angular/compiler?fields=name,description
https://api.cdnjs.com/libraries/%40angular%2Fcompiler?fields=name,description

am I missing something?

Hello, is there any way to filter by file type?
Like this：
https://api.cdnjs.com/libraries?fileType=css

• when the cdnjs api worker is done, Algolia will be updated by the api-server
• (will update this later with more details)

@MattIPv4 feel free to update this

We are missing mjs here

Edit: Just noticed you already added it @MattIPv4. Still doesn't show up on the whitelist for me though, maybe needs to be deployed? ... maybe I'm just crazy 🤔

Apply the whitelist to the files property of a library object as well as the keys in the sri property if a library object.

i want to get the same data as the picture show from you website,
so i send address:''https://api.cdnjs.com/libraries?search=jquery&limit=5".
But it doesnot work. The data returned is not correct.
what should i do? help me please!

Add an endpoint that returns an object with two properties:

• extensions: an array of all file extensions in the whitelist
• categories: an object mapping each extension to a category (eg images)

Description

The version sorting seems to have no rhyme or reason.

Steps to reproduce

• Visit page: https://cdnjs.com/libraries/highlight.js
• Open dropdown.

Expected behavior

The order would be newest first, followed by older releases in release (or at least version order). IE something like:

• 11.0.1
• 11.0.0
• 11.0.0-beta2
• 11.0.0-beta1
• 10.7.3
• 10.7.2
• 10.7.2-beta0
• 10.x ...
• 9.x ...
• 8.x ...

Screenshots

Details

There is invalid JSON at https://api.cdnjs.com/libraries/jquery-validate (see end of the document):

...
"sri":{"additional-methods.js":"sha512-5PDORojuUAKi3sd4xcqVI+ZtPs9QT6lPHG5LbwrqWlTFwK22Bewya3IVObPvaUFX6DUXUVvE1qABX4U0mU09mQ==","additional-methods.min.js":"sha512-Pk8WfSRH6frVrOJMzqDcDTVDDBeHvGZEDtEiULZdTOuumP/vz5QxuHSE1lisKdocrCs2e8F4IAjkDjZR/HFSzA==","jquery.validate.js":"sha512-F41aKGb1IjCLJVsV8Gcz+FTp2r6iUGTanYIyxbE8Nasq4dYDgv4l39sL7bpyL2J3LiHgWii0zzG9IsGY+4vMjw==","jquery.validate.min.js":"sha512-mnn/B8z6KVHa04hFn5hT0kLAn/j/0z4Ir3Kj41vvMosigCq1stpfiAF7lgPcKv/ua9dJXcJthXN5eMTJKzs2Dg==","localization/messages_ar.js":"sha512-U+6AxJtnHBTCrIeBLoqFswvn1dZbWGkGrSK17fW3qv0KLouZ/dz5U4wl8oGyGC048VSKOjLooi27BaiolIN82A==","localization/messages_ar.min.js":"sha512-XpuXsmAxK0Z49EebDHTnwLmOfsKwc04dhopPI0C5u5VDza41UF/zpT/Bg4/2qnTwOTFx6Crhxz5AVi5AHtEBnw==","localization/messages_bg.js":"sha512-R3Kl0eqlqHkIffFAtW0ylMFI0V/sab35/V3oEUai7ESTyPr65OGy0jvtFrN2/gLQFXGz7MniiuxsyDSiQyMiNg==","localization/messages_bg.min.js":"sha512-EVHsVjXaylvI7jeqix89I6ncSqUeJaqHJkfk0lr4lQSFSp4jMxcrFqmKsnqj4GapkzwFGcCHcu5nY63KDNIwsw==","localization/messages_ca.js":"sha512-wh+/iv0LwUZgPPH8A5mB+JosQufF9YGl9vcmDtOYhMWIAARWbnnI1xRWI90FzbPT3Fm6dtIJG09/2GPn4Ao6lw==","localization/messages_ca.min.js":"sha512-HoCsVwZTE3eVMmE4dedFnuUILGZgKGuwIske7lC7qC4mhlLJeckCjVNgeIoPcj3zpwbA+r3BVRJOipbk0sim1Q==","localization/messages_cn.js":"sha512-GFtoKnPo5dQcOkc0alESIgSVE8sHmzbs1E7jO3H8Uc

For jquery the JSON-output is valid.

Description

We used libman (by Microsoft) for getting frontend packages from cdnjs for our web app.
But 2 days ago error LIB002 was happen.
We analyze this problem and detect broken JSON from cdnjs api server.

Steps to reproduce

1. Go to https://api.cdnjs.com/libraries/jquery-validate (curl https://api.cdnjs.com/libraries/jquery-validate)
2. Parse JSON
3. Get deserialization error

Expected behavior

1. JSON shoud be valid :)

Logs

jquery-validate.json.txt

As we move cdnjs to running on KV, the metadata for packages that we currently we use to power the API will also move to KV, no longer being available in a single, massive JSON file.

As such, the API will need to be updated to pull the package metadata from a new Workers endpoint that exposes the KV metadata.

The test endpoints for now are http://metadata-staging.speedcdnjs.com/packages to get a list of package names and http://metadata-staging.speedcdnjs.com/packages/:package to get metadata for a package.

To begin testing this, we should implement the loading logic alongside the old packages.min.json logic and test that the two data sets are identical.

Idea: Maybe we can make a markdown file in this repo explaining the endpoints of the worker.

I can redirect http://metadata.speedcdnjs.com and http://metadata.speedcdnjs.com/help to that page.

Write tests for each API endpoint using Mocha, Chai & Chai-HTTP to ensure that all changes to endpoints are tested going forward.
Run this via a GitHub Actions workflow on every push.

Vulnerabilities

DepShield reports that this application's usage of debug:2.6.9 results in the following vulnerability(s):

• (CVSS 7.5) CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')

Occurrences

debug:2.6.9 is a transitive dependency introduced by the following direct dependency(s):

• body-parser:1.19.0
        └─ debug:2.6.9

• compression:1.7.4
        └─ debug:2.6.9

• express:4.17.1
        └─ debug:2.6.9
        └─ finalhandler:1.1.2
              └─ debug:2.6.9
        └─ send:0.17.1
              └─ debug:2.6.9

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

Vulnerabilities

DepShield reports that this application's usage of express:4.17.1 results in the following vulnerability(s):

• (CVSS 7.5) CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

_{This is an automated GitHub Issue created by Sonatype DepShield. Details on managing GitHub Apps, including DepShield, are available for personal and organization accounts. Please submit questions or feedback about DepShield to the Sonatype DepShield Community.}

When doing a search using the api and the string is too big Algolia will reject it. We should check the size against their constant

2020-05-06T06:33:43.000 36com265    'Invalid value for \\"query\\" parameter, expected string shorter than QUERY_ARGUMENTS_LIMIT_QUERY_MAX_LEN bytes',
2020-05-06T06:33:43.000 36com265   message:
2020-05-06T06:33:43.000 36com265 { name: 'ApiError',
2020-05-06T06:33:43.000 36com265   transporterStackTrace:
2020-05-06T06:33:43.000 36com265   status: 400,
2020-05-06T06:33:43.000 36com265        host: [Object],
2020-05-06T06:33:43.000 36com265        response: [Object],
2020-05-06T06:33:43.000 36com265 ::ffff:127.0.0.1 - - [06/May/2020:06:33:43 +0000] "GET /libraries?search=(big string...) HTTP/1.1" 200 38 "-" "Go-http-client/1.1"
2020-05-06T06:33:43.000 36com265        triesLeft: 3 } ] }
2020-05-06T06:33:43.000 36com265    [ { request: [Object],

Searching for "jqueryui" using the following string, not only is "jqueryui" is NOT displayed in the results, neither are any other libraries where "jqueryui" or "jQuery UI" are included as either keywords/tags or are used in the library's description.

https://api.cdnjs.com/libraries?search=jqueryui&output=human&fields=filename,homepage,version,keywords,description

Whereas by removing "description" from the "fields" list, and searching for "jqueryui" using the following string, "jqueryui" IS displayed in the results... as are all the other libraries where "jqueryui" or "jQuery UI" are mentioned.

https://api.cdnjs.com/libraries?search=jqueryui&output=human&fields=filename,homepage,version,keywords

Details

Description

The filename and latest (not sure if any other) fields return incorrect values via /libraries endpoint for some libraries, while correct data is returned via /libraries/:library endpoint.

Steps to reproduce

Data for a library "caf" as returned by https://api.cdnjs.com/libraries?fields=name,latest,version,filename:

{
    "name": "caf",
    "latest": "https://cdnjs.cloudflare.com/ajax/libs/caf/13.1.1/caf.js",
    "version": "13.1.1",
    "filename": "caf.js"
},

Data for the same library as returned by https://api.cdnjs.com/libraries/caf?fields=name,latest,version,filename:

{
    "name": "caf",
    "latest": "https://cdnjs.cloudflare.com/ajax/libs/caf/13.1.1/umd/caf.js",
    "version": "13.1.1",
    "filename": "umd/caf.js"
}

Expected behavior

/libraries should return the same data as /libraries/:library

Logs

N/A

https://api.cdnjs.com/libraries?fields=version,fileType

This gets the fileType null

How to obtain ?

https://user-images.githubusercontent.com/48686959/210209757-dbfe5293-284a-4a86-9b1d-f7bf02b8e240.png
The document says to pass the fileType field, but returns null

After this commit a66a3fb (I'm not sure)
https://api.cdnjs.com/libraries/?search=boo will return 404, but many proj use this route to search , I think new commit should be compatible with this route to ensure that no one else makes code changes to there proj.

Use eslint to ensure consistent code styling & quality.
Include an .nvmrc file in the repo & use GitHub actions to run the lint on every push.
(See setup in https://github.com/cdnjs/static-website)

I have implemented a sample project with the help of cdnjs api for searching libraries and onclick result it shows the library details and files name but I want to link the filenames with their url

Please help me???

Add some basic docs to a README file covering running this in development as well as how it will update & run in production.

Add deployment-related files from https://github.com/cdnjs/new-website and ensure that tutorials/sris are updated at start like packages.min.json

Details

Description

The fields homepage and description of my package on cdnjs.com has not been updated after cdnjs/packages#1112 has merged.

Steps to reproduce

• I request a PR to update homepage, description, and repository url in cdnjs/packages cdnjs/packages#1112

• I also published a new version of 4.9.2 trying to trigger the update

Expected behavior

Logs

• cdnjs/logs shows the new info has been update in to the kv store
  cdnjs/logs@b061c3c

• However, https://api.cdnjs.com/libraries/react-inputs-validation shows the outdated information

Both filename and version could be missing from the data, the API server needs to handle this and should not generate a top-level latest or sri value in this case.

We should implement an update job within the API server that runs in the background every x minutes to clone the latest versions of the SRIs & tutorials repos as well as pulling down the latest package data.

This would remove the need to continual re-deployments of the API server, and assuming a decently fast interval for the update job (maybe every 10 minutes), it would mean the only remaining blocker for getting the API more realtime is how often we update the SRIs & packages data directly.