-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate EIP712 authentication provider #532
Deprecate EIP712 authentication provider #532
Conversation
✅ Deploy Preview for taco-nft-demo ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for taco-demo ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
9c7fdcd
to
37cbd5d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we outright remove EIP712 support instead of deprecating it? If not, what is a good timeline to allow taco-web users to adjust?
Since it was implicit before I think it can just be removed. The associated new context variables can also be removed because they were never publicly released.
I think (?) the concern you are raising is a question for nucypher
code instead of taco-web
because everything was so implicit in the past - see the notes for reviewers in nucypher/nucypher#3515.
Let me know if I'm missing something.
packages/taco-auth/src/types.ts
Outdated
export const EIP712_AUTH_METHOD = 'EIP712'; | ||
export const EIP4361_AUTH_METHOD = 'EIP4361'; | ||
|
||
export const USER_ADDRESS_PARAM_DEFAULT = ':userAddress'; | ||
|
||
/** | ||
* @deprecated Use USER_ADDRESS_PARAM_EIP4361 instead. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These context variables were never publicly released - just the epic, right? If so, then a removal can be done instead of deprecation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
They were never exposed to the taco
API, but the values they represent were in use, hence they should be deprecated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure I follow. Who used them in a released version? AFAIK they were only used internally for examples, and only in the epic. Am I mistaken?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, I think you are right. I think that was my mistake. I will fix it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
^ Is the goal to remove these additional context variables in a separate PR then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there's a follow-up issue for that: #536
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But these don't need to wait T+2 releases to be removed ... ?
console.warn( | ||
'DeprecationWarning: The default authentication provider, EIP712AuthProvider, is deprecated. ' + | ||
'Please use EIP4361AuthProvider instead. Refer to the documentation for more details.' | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since the use EIP712 was implicit until now, is this necessary?
EIP712AuthProvider
was not actually used/specified by anyone in prior releases. Can we simply remove it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMHO it doesn't matter if behavior is implicit or explicit, only whether the changes in the API are breaking, and this is a breaking change
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with the intention of the warning, but should we refrain from still calling it the "default"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I follow. I believe this file/module and the class was only added as part of the unreleased epic (the epic we are merging this PR into), so why keep the file/module and the class that we no longer intend to use as part of that epic and was never released...
By "implicit" I mean that no user has ever specified or created a EIP712AuthProvider object, because it was never released. So there is no real "breaking" for this class/module since has never been released. The broader API (decrypt
) will indeed have "breaking" changes but that is irrespective of this particular auth provider, or the scheme used for validating wallets.
It's possible that a warning could be used somewhere, but I don't think this is the spot, since it seems like this file/module should just be deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We've released an API with a documented behavior (using EIP712 by default) and are now replacing that behavior with another (EIP4361). I don't know specifically how this change can affect our users (is it going to "break" anything) but changing the implicit (or explicit) behavior of an API is a breaking change (according to semver).
Deprecating EIP712 in T+1 major version will allow us to communicate this breaking change to users who are currently using EIP712. Again, I don't know whether it will actually break something, but it makes sense to announce it and only remove it in T+2 after this upcoming change is communicated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. Ok, so the goal of keeping the file is more to keep this (EIP712) as an option (albeit a pending deprecating one), in case some adopter decides they want to use EIP712 instead of EIP4361 for :userAddress
for now until we fully deprecate. That's the reason for keeping this module for now.
If we are affording that option, then the server-side will need to be adjusted to accept both EIP712 and EIP4361 for :userAddress
and nucypher/nucypher#3515 will need to be adjusted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the server side verification will be broken for EIP712 in the next release? Not deprecated, but outright removed?
In that case, these changes have no sense and we should remove EIP712 from the client too. I will address it in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the server side verification will be broken for EIP712 in the next release? Not deprecated, but outright removed?
That's still a discussion for #3515, and not currently set in stone. We still need to make an official decision there.
37cbd5d
to
c13f172
Compare
517fb14
to
09f5732
Compare
4eea8e7
to
5a4d072
Compare
09f5732
to
ef0b40c
Compare
ef0b40c
to
5a4d072
Compare
Accidentally closed during a rebase |
Type of PR:
Required reviews:
What this does:
EIP712AuthProvider
as deprecatedIssues fixed/closed:
Notes for reviewers:
taco-web
users to adjust?