Releases: pimeys/rust-web-push
v0.10.2
v0.10.1
Changelog 🗒
[ + ] Add support for Topic headers (#41) (Thanks @depressed-pho!)
[ ~ ] Improve error messages (#54 ) (Thanks @niklasf!)
[ ~ ] Bump to v0.10.1
v0.10.0
Changelog 📝
Additions
- Clients now all impliment a common trait,
WebPushClient
, rather than relying on overloading the same name with conditional compile. This allows for one to use more than one client implimentation at the same time.
Fixes
- Aud claims now have correct formatting (Fixes #50)
WebPushBuilder::new
now no longer returns Result for no reason (Fixes #47)
Breaking Changes ⚠
WebPushClient
now refers to a trait, rather than a feature selected struct. Now, you must explicitly useIsachWebPushClient
orHyperWebPushClient
depending on your feature flags.WebPushBuilder::new
no longer returns a Result
v0.9.5
Changelog 🗒
[+] Add AesGcm enocding (see #44 for justification)
[+] Add filler sub
claim to all tokens, unless the claim is added manually
[+] Add tests for aesgcm
[+] Update documentation to make examples more promenent
[+] Bump to 0.9.5
Bug Fixes 🐜
- FireFox would reject pushes where a
sub
claim was not added, despite the fact that this is not part of the push standard. To solve this issue, a dummysub
claim of 'emaito:[email protected]' is added to all messages. This will not effect any services already adding thesub
claim manually.
v0.9.4
v0.9.3
Changelog 🗒
[+] Add support for base64 encoded private keys. This brings this web push implimentation in line with others like php and node in supporting keys from VAPID key generator sites.
[+] Reexport some base64 constants to support the above feature
[~] Update dependencies
[-] Remove pkcs8 crate, as its utilities have been replicated in jwt_simple
[+] Bump to 0.9.3
v0.9.2
Changelog 📄
[+] Impl Clone for both clients.
[~] Move to Rust 2021.
v0.9.1
Changelog 📄
[+] - Add Clone, Ord, PartialOrd, Eq, Deserialize, Serialize, Hash
traits to public facing structs.
[+] - Bump to 0.9.1
v0.9.0
Changes 📝
[~] - Delegate JWT signing and key management to jwt_simple.
[~] - Manually ensure compatibility with both SEC1 and pkcs8 encoded PEM keys.
[+] - Add WebPushError::InvalidClaims variant for use when invalid JWT claims are used.
[+] - Add pkcs8, pem, and sec1_decode crates to handle PEM decoding.
[~] - Make lazy_static a dev dep.
[~] - Migrate futures to futures-light and feature gate behind the isahc client.
[-] - Remove openssl, ring, time, native_tls, and futures deps.
[+] - Improve tests.
[+] - Improve docs.
[+] - Bump to v0.9.0
v0.8.0
Changelog 📝
Additions
[+] - Full aes128gcm support via ece crate. Credit to @tiesselune for this. See #23 for more. Closes #3.
[+] - Isahc based default client to remove Tokio dependency. Separate changes from #25 but similar effect, although Isahc works on any executor as it uses curl under the hood.
[+] - Cargo feature to enable the old hyper client.
[+] - Generic build_request() to allow for custom clients using the http crate's generic request body. This function is also exported now. This should enable someone to make a say, ureq web push client crate, without our input.
[+] - Add function to create a VAPID builder without a sub, allowing for key material to be reused.
[+] - Method to get the public key bytes from a Vapid signature (useful for sending the key to client without messing with openssl).
[+] - Improved tests and added one to actually test the encryption itself.
[+] - Expand documentation throughout the code base, and update docs to accurately reflect the current web push API.
[+] - Bump to v0.8
Deletions
[-] - Remove all aesgcm code. This significantly reduces maintenance by reducing tests and removes concerns of deprecation. This is possible because of aes128gcm's universal support.
[-] - Remove old GCM/FCM code. This is redundant now that web push is standardized.
Breaking Changes ⚠
WebPushClient::new()
now returns aResult
as the Isahc client has a fallible constructor. This has been applied to both clients to keep the API the same, although the hyper client is infallible.- Removal of all gcm/fcm methods on builders. I believe the FCM crate may be a valid upgrade path if FCM is heavily used.
- Removal of
ContentEncoding::AesGcm
. Because all tested APIs support (and in the case of Edge only supports) Aes128Gcm, consumers should simply replace the variant withContentEncoding::Aes128Gcm
.