Comments (3)
One thing I appreciated about your library (I'm new-ish to JS) was how well organized it was for the tree shaking and test coverage.
Thanks for noticing, I've tried to put enough emphasis on those things. 😅
The nice thing is you could still do an if statement off of the truthiness of the integer returned and get the same behavior.
Yeah, exactly. It probably won't even be breaking for most people (doing loose truthy/falsey checks) but technically it will be, so we'll bump major.
Since isAHash was previously needed for an API ambiguity, can we drop it and drop configuration on this function call all together?
Let's drop it. Consumers will lose the ability to submit a hash using pwnedPassword
but they could still do it via pwnedPasswordRange
if they really wanted to re-implement pwnedPassword
functionality on their end to avoid the library processing the password (that's what I do now in the CLI package, which I'll be able to revert once we implement it here). This will be a breaking change, too, so bumping major definitely makes sense now if there was any question before.
from hibp.
Hey @danieladams456, thanks for bringing this up!
When I saw the new search-by-range feature, I rushed to create pwnedPasswordRange.js
to support it. I left pwnedPassword.js
alone in case consumers wanted to use it for some reason, but I agree it would be nice if it used the more secure API (I can't think of a reason you'd want/need to send the password over the wire).
I do wonder if maxPwns
is too use-case specific. I'd like to keep the public API surface as small as possible and I'm not sure adding an option to save consumers a one-liner check downstream is worthwhile. Perhaps pwnedPassword
should return a count (number of occurrences) and leave that logic to the consumer? It would be a breaking change, returning a number instead of a bool, but I'm totally OK with a major version bump if needed. Thoughts?
from hibp.
One thing I appreciated about your library (I'm new-ish to JS) was how well organized it was for the tree shaking and test coverage. I agree that using the more generic case of returning an integer would be less limiting for the consumer since it more closely mirrors the upstream API. If you're good with a major version release that sounds like a plan to me. The nice thing is you could still do an if statement off of the truthiness of the integer returned and get the same behavior.
Since isAHash
was previously needed for an API ambiguity, can we drop it and drop configuration on this function call all together? Since the hash is an unsalted SHA-1 and no one should be actually storing passwords that way, I wouldn't think someone would need the use case of submitting a password from a DB they don't have the plaintext for. One nice ability gained by keeping the switch would be for the consumer to hash the password before calling the function so he doesn't have to trust the library quite as much since he controls the hashing. What do you think?
from hibp.
Related Issues (20)
- Add API key support for paid endpoints (namely, `breachedaccount` and `pasteaccount`) HOT 1
- Update documentation for API v3 HOT 1
- Action Required: Fix Renovate Configuration
- CORS Error HOT 1
- Refactor pwnedPasswordRange to resolve with object? HOT 2
- All Contributors HOT 14
- Dependency Dashboard
- Is there timeout on fetch? HOT 2
- Rate limiting `retry-after` HOT 2
- Error - "You may need an appropriate loader to handle this file type" HOT 5
- Not finding realy simple passwords HOT 3
- Forbidden - no user agent has been specified in the request. HOT 17
- Errors in web workers or extension background threads HOT 9
- TypeError: Cannot read properties of undefined (reading 'startsWith') HOT 4
- Hudson Rock Cybercrime Intelligence Free Integration
- Request blocked or forbidden HOT 8
- Cannot use hibp modules in React Native development mode HOT 3
- Update rate limit handling HOT 1
- Invert `includeUnverified` option on `breachedaccount` endpoint HOT 1
- Invert `truncateResponse` option on `breachedaccount` endpoint HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from hibp.