Skip to content

v1.1.0: New APIs, better testing and more type safety

Latest
Latest
Compare
Choose a tag to compare
@wneessen wneessen released this 27 Feb 15:35
v1.1.0
2e46246
This commit was created on github.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Welcome to go-hibp v1.1.0!

Important

This release breaks current implementations. Please read the release notes and the code documentation before you update to this version.

Note

This is supposed to be a v2 release, to comply with semver semantics. But given that some Go tools are not able to handle v2.x.x as version number and requiring us to create a separate branch or subdirectory for v2, I've decided to go with v1.1.x for this release instead. While this break semver, I think this module is not used widely enough to justify the v2 branching.

New HIBP APIs

Client changes

  • Custom HTTP client: PR #36 adds support for a custom HTTP client provided by the user. This can be useful if you want to customize the HTTP client. Thanks to @AndreZiviani for the PR!
  • Custom logger support: PR #37 removes the default usage of log.Printf and replaces it with a custom logger that has to satisfy the io.Writer interface. This is to avoid frequent and cluttered the logs in production environments due to rate limiting. Thanks to @tekkamanendless for the PR!
  • Talking about rate limiting... PR #41 adds one second to the rate limit delay to avoid rounding issue. PR also provided by @tekkamanendless

Better testing

PR #44 overhauls the complete testing suite. Instead of running lots of test against the online HIBP API (which usually results in lots of rate limiting) we now provide a proper mock server emulating valid and invalid responses. Most tests are run against the local mock server and only one test per API is executed against the online API for integration testing. This not only makes the tests run faster, since we do not have to wait for long rate limit times, but we can also simulate scenarios that we weren't able to test before, resulting in better test coverage. We are now at ~97% of coverage compared to the ~80% beforehand.

Removal of pointer type returns (BREAKING CHANGE)

PR #44 (and #45 in fact) also changes the returns types of all APIs that would return a pointer type to return actual types instead. This reduces the chance of nil pointer dereferences. To make sure the user can still check if the API returned something or not, every type now provides a Present() method indicating if the API returned the value or not. This change will break current implementation but I think it's a good step to avoid unnesessary pointer returns.

Replacement of nil types in JSON returns (BREAKING CHANGE)

In the same run, nil types in JSON returns were also changed. In case an API returns null-able types in the response, so far we've handled this with pointer types (like *int). This is also a possible cause for nil-pointer dereferences. Therefore these types have been replaced with my niljson which provides type safe access to null-able JSON return types. This will also break current implementations and will introduce a new dependency to your go.mod.

Unified API date type (BREAKING CHANGE)

Last part of the #44 PR was to unify the APIDate type. The custom APIDate type has been made suitible for the different date types retured by the HIBP API (ISO8601, YYYY-MM-DD). It has also been simplified by putting it into a struct. It can now be handled like a normal time.Time type instead of having to make use of the .Time() method. The RenewalTime type has been removed accordingly.

Fix of HTTP 404 returns (POSSIBLY BREAKING CHANGE)

While implementing the new testing suite in #44, I noticed that some APIs return a HTTP 404 i. e. if an account is not listed in a paste (or similar). This 404 would, until now, cause the API request to return an error. This is misleading since the "NotFound" basically indicates that the account was not breached/leaked. This behaviour has been fixed for the corresponding APIs and returns nil instead of an error if a HTTP 404 is received. This will likely break implementations but is the actual correct way to handle the responses.

API key checking for APIs that require such. (POSSIBLY BREAKING CHANGE)

All APIs that require an API key to query the HIBP API are now checking if the API key has been set on the client before sending the HTTP request. If the API requires key and no key has been set, the method will fail with an error and not query the online API.

What's Changed

Github Workflow changes/maintenance changes

New Contributors

Big thanks again to all contributors for their PRs, reviews, issues and comments. Your support is highly appreciated!

Full Changelog: v1.0.7...v1.1.0

Contributors

freman, wneessen, and 2 other contributors
Assets 2
Loading
0 Join discussion