Alpha release of v2.0.0. Adds support for custom token types to be used, so that users of this library can manually manage (de)serialisation of token claims and footer.
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.5.2...v2.0.0-alpha
Published by aidantwoods 3 months ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.5.1...v1.5.2
Published by aidantwoods 11 months ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.5.0...v1.5.1
Published by aidantwoods over 1 year ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.4.0...v1.5.0
Published by aidantwoods over 1 year ago
This is an fairly large internal change around how results + errors are being represented. There should be no change to any consumer facing behaviour from the public API perspective.
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.3.0...v1.3.1
Published by aidantwoods over 1 year ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.2.1...v1.3.0
Published by aidantwoods over 1 year ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.2.0...v1.2.1
Published by aidantwoods almost 2 years ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.1.3...v1.2.0
Introduces two specialisations on errors that may be returned: TokenError
and RuleError
. Note that some error
s will still be returned by the library that are in neither of these specialisations, and so you should still fallback to general error handling (not assume one of these will always be returned).
A TokenError
will be returned if the token is outright invalid in some way, whether that be due to formatting, a cryptographic issue, or some other issue which renders the token invalid.
A RuleError
will be returned if a token fails one of the specified rules, but is otherwise valid (including cryptographically).
Distinguishing between these two error types is not mandatory: it is perfectly safe to just handle a general error without inspecting it. Being able to inspect an error may be useful for some use cases, for example if a different handling action is desired depending on whether the token was invalid or whether a rule failure occurred. Note that if you do look for one of these errors, you should additionally include code to handle general errors as a fallback: you should expect new errors that do not fall into either of these two categories to be returned in the future.
Published by aidantwoods about 2 years ago
NotBeforeNbf
rule, which can be used the check the current time is after or equal to the token's nbf
claim.NotExpired
checks according to the time when the rule is run, not when the rule is createdFull Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.1.2...v1.1.3
Published by aidantwoods about 2 years ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.1.1...v1.1.2
Published by aidantwoods over 2 years ago
Full Changelog: https://github.com/aidantwoods/go-paseto/compare/v1.1.0...v1.1.1
Published by aidantwoods over 2 years ago
This minor release adds support for version 3 public of the PASETO spec.
Additional information: https://github.com/aidantwoods/go-paseto/pull/1
Published by aidantwoods over 2 years ago
Message
type: this was added for consistency with the swift-paseto library, but I opted to simplify the API here considerably by not exporting the low level Paseto crypto operations. The Message
type only really makes sense when using those low level operations.Published by aidantwoods over 2 years ago
Version 1 stable release!
Support for common claims validators, full support for v2 and v4, and partial support for v3. Full support for v3 expected to be added in a later feature release.