Releases: spruceid/siwe
SIWE 2.1.4 Release
SIWE 2.1.3 Release
This restores previous behavior for issuedAt
where it was optional and by default set to new Date().toISOString()
.
SIWE 2.1.2 Release
Dropping support for RegExp
Due to small inconsistencies between the ABNF grammar and the RegExp parser it was decided that it will no longer be supported and as of this version was removed. (#120)
Library improvements
With this release is now possible to extend the behavior of the verify
function. Using the argument verificationFallback
in the VerifyOpts
object makes it possible to create a custom condition for verifying a SIWE message in case of failure (#85).
verificationFallback
requires a function that has the same return as verify
(Promise<SiweResponse>
) and is provided with four arguments, those being:
params: VerifyParams
: same params used in theverify
call;opts: VerifyOpts
: same opts used in theverify
call;message: SiweMessage
: the message currently being verified byverify
;EIP1271Promise: Promise<SiweResponse>
: the result of the verification if the message was signed by a SmartContract Wallet.
Thanks to #99 a big performance upgrade was also possible making the library even better.
Additional tests were also introduced, additional checks and safeguards and general improvements to code quality.
SIWE 2.0.5 Release
Fix
- Fixes a build issue from
2.0.4
where adist
folder with nested files was created from an added flag to enable typing for the JSON tests. These issues have since been resolved (#91).
SIWE 2.0.4 Release
To improve code quality and allow for easier contribution two new scripts to check for code smells and lint the code were added to package.json
:
lint
, which checks for code smells.format
, which fixes code accordingly to lint and format rules.
The deprecated function validate()
was returning the result of the new function verify()
, which was not the previous behavior therefore it is being fixed on this release to return the previous object (SiweMessage
), tests were also added to make sure existing behavior will be maintained while this function is supported.
Upgrading from SIWE 1.x to 2.0
As mentioned in the previous release for most implementers, the existing code will continue to work as expected without changes, but there will be a warning message that validate()
has been deprecated, and may be removed in future versions. To get rid of this warning, you can simply update instances of validate(signature)
to const { data } = verify({ signature: signature })
.
SIWE 2.0 Release
SIWE 2.0 has been released. The interfaces have been updated to allow consistent usage across languages for SIWE message parsing, creation, and verification. Message parsing has been split into its own package, siwe-parser
, allowing implementers to utilize this functionality standalone without importing larger cryptographic dependencies.
As a result, this update introduces the following breaking changes (hence the major version update) and implements stricter checks from the EIP-4361 specification:
validate(…)
was deprecated and renamed toverify(…)
with a new API. A backwards-compatible helper function exists to allow existing implementers to upgrade without concern for changed behavior, but SIWE 1.0 users are advised to review the upgrade section below.ethers
has been updated to a peer dependency, allowing for more efficient builds.- EIP-55 validation of EIP-155 is now enforced, and non-EIP-155 messages are considered as invalid.
- The
type
andsignature
properties have been removed fromSiweMessage
. - The
not-before
message field is now checked duringverify
. - This update introduces more granular error types returned after verification or message parsing failures:
EXPIRED_MESSAGE
,INVALID_DOMAIN
,DOMAIN_MISMATCH
,NONCE_MISMATCH
,INVALID_ADDRESS
,INVALID_URI
,INVALID_NONCE
,NOT_YET_VALID_MESSAGE
,INVALID_SIGNATURE
,INVALID_TIME_FORMAT
,INVALID_MESSAGE_VERSION
, andUNABLE_TO_PARSE
.
Upgrading from SIWE 1.x to 2.0
For most implementers, the existing code will continue to work as expected without changes, but there will be a warning message that validate()
has been deprecated, and may be removed in future versions. To get rid of this warning, you can simply update instances of validate(signature)
to verify({ signature: signature })
.
validate
(SIWE 1.x) vs verify
(SIWE 2.0)
Instead of validate(...)
, SIWE 2.0 uses verify(params, opts)
. The verify
function accepts the primary argument params
, which satisfies the following interface:
export interface VerifyParams {
/** Signature of the message signed by the wallet */
signature: string;
/** RFC 4501 dns authority that is requesting the signing. */
domain?: string;
/** Randomized token used to prevent replay attacks, at least 8 alphanumeric characters. */
nonce?: string;
/**ISO 8601 datetime string of the current time. */
time?: string;
}
The opts
argument contains the options which dictate how the verification should proceed, namely:
export interface VerifyOpts {
/** ethers provider to be used for EIP-1271 validation */
provider?: providers.Provider;
/** If the library should reject promises on errors, defaults to false */
suppressExceptions?: boolean;
}
Finally, the verify(...)
function returns an object of type SiweResponse
defined as:
export interface SiweResponse {
/** Boolean representing if the message was verified with success. */
success: boolean;
/** If present `success` MUST be false and will provide extra information on the failure reason. */
error?: SiweError;
/** Original message that was verified. */
data: SiweMessage;
}
With the suppressExceptions
option above, a SiweResponse
with a populated error will be resolved instead of the promise being rejected, allowing for normal control flow handling. However, by default, promises are rejected to ensure defensive programming practices.
v1.1.0
v1.0.0
This updates the library version to 1.0.0, with a newly stabilized API.
- Renamed signMessage() to prepareMessage(): Functionality remains the same, but signMessage() is deprecated and will be removed in future releases. It will warn upon usage.
- The SignatureType enum is also deprecated and will be removed in future releases. Type will now be inferred from the version of the message.
- With the removal of the SignatureType enum there will be no use for the field type, which is now deprecated as well and will be removed.
The field signature is deprecated and will be removed in future releases. - BREAKING CHANGE The method .validate(provider) now require a new argument signature, which until the removal of the field signature from message will be not required and inferred from it. If this method was being used with a provider as an argument the signature will have to be provided.
- Tests and the Notepad example were updated to work with these changes.