-
Notifications
You must be signed in to change notification settings - Fork 315
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
fix: remove username matching #1230
Conversation
This pull request is being automatically deployed with Vercel (learn more). 🔍 Inspect: https://vercel.com/blockstack/stacks-js/5ZoPambcNLVJqV8fmXmFzbPkNZfC |
d2418bd
to
4285113
Compare
4285113
to
022efda
Compare
022efda
to
93683a3
Compare
Codecov Report
@@ Coverage Diff @@
## master #1230 +/- ##
==========================================
- Coverage 64.10% 64.00% -0.10%
==========================================
Files 123 123
Lines 8619 8574 -45
Branches 1830 1818 -12
==========================================
- Hits 5525 5488 -37
+ Misses 2986 2978 -8
Partials 108 108
Continue to review full report at Codecov.
|
95c634a
to
bbbf990
Compare
bbbf990
to
2e95a32
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.
Nice improvement @janniks.
This never made sense to me: if the registrar is down, you can't verify an auth response? 🤷🏼
@janniks Any ETA on when this PR might get released? We're hoping to incorporate it into out test app so we can QA leather-io/extension#2303 again |
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.
This is fine to me, so long as you're all clear on what the goal is here: removing application validation of BNS names. Without this validation, applications can no longer trust that the BNS name that the authentication response provides is actually owned by the claimed user.
Per @kantai's point here, I wonder what documentation may need updating to make this change of behavior clear. And perhaps we should pair this with removing usernames from the auth responses in general, to prevent developers from assuming incorrectly that they've been verified? @janniks want to audit the docs for such possible updates and make the auth response change as well? |
I'm thinking a major release bump and changelog mention. But I'll go through the docs to see what should be updated.
Yes, good point! I'm removing these now and checking how it ties in to the user session data. |
BREAKING CHANGE: This change REMOVES the `username` attribute from auth token payloads and therefore also from userData in @stacks/connect. Hence, there is NO MORE username verification done by @stacks/connect automatically.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
98bff3f removes the |
👍 this seems like a safer approach than just documentation changes. It seems like a token version bump would make sense with this change -- it would help apps that may want to explicitly check for this rather than having to infer it. Should this change be brought up in stacksgov/sips#50? Ideally, that SIP would make a similar change or make the username optional. |
Yep we've been in touch with @friedger about this functional change. @janniks I'd suggest leaving a comment about it on the above SIP PR whenever you have a chance as well, to help with visibility. |
c2c66e7
to
b25b3c4
Compare
✅ great input! will merge and beta-release to test |
scope
EDIT: now removes the
username
field completely fromauth
removes username matching from auth package (application-side)currently — in applications using @stacks/connect — the @stacks/auth package will "validate" usernames which the wallet returned in the authResponse. as "validation" these usernames are matched to the response of the API's
/names
endpoint.the matching is removed fromverifyAuthResponse
. in addition, the previously useddoPublicKeysMatchUsername
seems incorrect and is removed completely (only used inverifyAuthResponse
previously).comments
a second PR could investigate removing theusername
field from auth responses in general, as brought up here (should be coordinated w/ wallet-web).