-
-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Get rid of dependencies? #57
Comments
I'm going to look more into this today. At first glance think we should definitely remove |
It seems that the reason for |
Removing |
I would prefer that we remove those dependencies. Just simply by the fact, that it reduces the surface for potential attack vectors. |
You mentioned that integrating or resolving those dependencies would be a major version. I kind of disagree. It would be more of a minor change, as the interfaces would not be changed. |
@Uzlopak I think what you did would be fine for a minor change but I don't think we should throw the errors. They should be returned. |
Hmm, we could return Errors, but would this not result in a deoptimization by V8 as the function gets polymorphic? |
These decisions (throw vs return) should also be consulted by the OAuth 2.0 standard RFC(s) in order to see what it states. We need to be compliant before being performant. |
First off @Uzlopak, thank you for taking the time to do this. I'm fine with throwing errors but I'm not a fan of throwing frivolous errors. Let's not crash the process when ultimately this is all that's true: if (typeof string !== 'string') {
return undefined;
}
The errors thrown on lines 53, 57, and 83 should also be |
I actually think that your suggested code is much better than taking that old stuff from basic-auth package. |
@jankapunkt any update on you want to approach these dependencies? |
@jorenvandeweyer I think we keep the |
I just checked a bit the current dependencies we have.
Regarding bluebird and promise I think we are good to remove them and they are covered by these issues already: #19 #20 #48
The other dependencies are the following:
type-is
npm: https://www.npmjs.com/package/type-is
github: https://github.com/jshttp/type-is
dependencies:
usage:
This project uses
type-is
to parse and classify request types (liketext/html; charset=utf-8
orapplication/json
).See in code: https://github.com/node-oauth/node-oauth2-server/blob/development/lib/request.js#L8
analysis:
While
mime-types
is updated regularly, thetype-is
andmedia-typer
have not been released in a few years but are at the same time downloaded in the ten-millions. This can mean they are quite mature but it could also mean that the owners may have not much time anymore to maintain.The may also have no 2FA setup yet (because a few years ago nobody cared so much but a few people who were security-aware).
We should ask the owners (directly via Email) if they have setup 2FA in order to prevent supply chain attacks on their repos, since their combination (yeaqrs ago released + 20 million downloads) would be targets for SCA in my view.
remove or not
I am not sure if removing makes things easier. Parsing is often a complicated thing and request types are variying a lot. Would need more analysis, if we need only a few types exclusively.
basic-auth
npm: https://www.npmjs.com/package/basic-auth
github: https://github.com/jshttp/basic-auth
dependencies:
usage:
This project uses
basic-auth
in order to retrieve and parse theauth
header of a request.See in code:
analysis
Both packages are not published in 2 years. Their usage is also in the millions. While I can't say about the activity for the owner of
basic-auth
I know at least for the author ofsafe-buffer
that he is actively maintaing his repos. The same thing applies regarding 2FA, we should ask the owners (directly via Email).remove or not
This is a more interesting issue, since parsing the auth header is way simpler than parsing thousands of combinations of requests. We also could get rid of both deps, since the node-native buffer should be sufficient.
The text was updated successfully, but these errors were encountered: