Add webauthn verification page #3310
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
@@ Coverage Diff @@
## webauthn-cli #3310 +/- ##
=============================================
Coverage 98.53% 98.53%
=============================================
Files 115 116 +1
Lines 3412 3423 +11
=============================================
+ Hits 3362 3373 +11
Misses 50 50
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What problem are you solving?
Part of #3298, which adds WebAuthn verification support to the CLI.
This follows up on #3305, which added the ability to generate a path token and send the verification URL containing that token in the API. Now, we replace the stubbed out
example.comhost for the token by creating the actual verification page that that URL leads to. We leave the work of actually doing the authentication dance to a future PR.What approach did you choose and why?
The verification url is only valid when given a valid, non-expired token, and it sets the user that you're authenticating as as the user for whom the token is for.
Valid Token:
Invalid Token:
What should reviewers focus on?
The 404 for invalid tokens is the same approach NPM takes, though they do add an error message to their 404 page that says "Invalid or expired token. Please try again." I considered adding that error here, however our 404 pages are completely static right now and don't take any dynamic content or flash messages. I ultimately decided that a 404 was clear enough without the message and the most idiomatic status. (After all, when you go to
rubygems.org/gems/invalid_gem_namewe don't give you an error explaining that the gem couldn't be found because the gem name is invalid. Its implied in the 404. Why would this be any different?) But I'm open to different opinions.