WebAuthn cryptically not working in production but works perfectly in development

Get Help and Help Others
10

Looks the exact same :confused:

11

Hmmmm…that object is created/handled by the simplewebauthn lib that we use, Redwood’s not creating that or messing with the contents at all. Is there a previous request to that, one that retrieves the registration options? The URL will be something like /auth?method=webAuthnRegOptions … what’s the payload/response of that one look like?

12

Here’s the source for the WebAuthn code if you’re interested: redwood/webAuthn.ts at main · redwoodjs/redwood · GitHub You can see there are four main functions there, one to get registration options, one to register, one to get auth options, one to auth. That’s the web side code, the api side is here: redwood/DbAuthHandler.ts at main · redwoodjs/redwood · GitHub

13

It looks like clientDataJSON is supposed to be a base64-encoded string so maybe that’s okay: SimpleWebAuthn/decodeClientDataJSON.ts at master · MasterKale/SimpleWebAuthn · GitHub

1 Like
14

yes! the response looks like this -

Screen Shot 2022-10-25 at 10.08.10 AM
Screen Shot 2022-10-25 at 10.08.10 AM1424×384 75 KB

15

I’ve also confirmed that it’s not an issue with the JSON stringification that’s being passed into send:

Screen Shot 2022-10-25 at 11.10.21 AM
Screen Shot 2022-10-25 at 11.10.21 AM2108×88 21.4 KB

16

Can you try adding a host entry in /etc/hosts so that you have a “real” domain name and access the site that way? Something like:

127.0.0.1 home.test

You’ll need to make a couple of config changes so that you can access the dev server from there.

In redwood.toml you’ll have to add the hosts line:

[web]
  title = "Redwood App"
  port = 8910
+ host = '0.0.0.0'

And then start the dev server with:

yarn redwood dev --fwd="--allowed-hosts all"

Then see if stuff still works going to http://home.test:8910

17

Hello, author of SimpleWebAuthn here. @arimendelow linked me here via an issue on the project’s repo. I figured I’d try and contribute here since there’s already an existing conversation.

There’s talk of a broken “production” environment here; is that publicly available? I want to throw in some breakpoints in the browser and see if something looks wonky on that environment.

And I apologize in advance if I ask some “dumb” RedwoodJS questions, I’m flattered the project uses my stuff but I’ve not yet used RedwoodJS myself :joy:

1 Like
18

Dude Kale, welcome! Thanks for coming over and offering to help!

1 Like
19

Welcome, @IAmKale! Thanks for taking the time to join us here :slight_smile:

I haven’t yet gotten to try out @rob’s latest suggestion, but yes that production environment is public at https://spoonjoy.app/

Steps to repro:

  1. Login here with the username tester1 and password test
  2. When you get the following screen, hit turn on. During that flow is where the error is thrown.
    Screen Shot 2022-10-25 at 12.12.22 PM
    Screen Shot 2022-10-25 at 12.12.22 PM976×596 28.3 KB

Thanks so much for your help and let me know if there’s any other info I can provide!

20

I found it, looks like http://spoonjoy(dot)co (I have to mangle this because I’m a “new user” and can’t post more than two links :unamused:) is the site? I’ll bet you what we’re dealing with here is a non-HTTPS website trying to use WebAuthn, and the WebAuthn call throws an error because WebAuthn needs to be used in a “Secure Context”: Secure contexts - Web security | MDN

21

The site probably works locally because “localhost” is considered a secure context, but an http:// address is not. The “Error while registering” at the start of the error message OP posted would line up with this logic in the except block that tries to handle registration:

Get some HTTPS on spoonjoy.co and I’ll bet you that’ll solve the problem.

P.S. WOW the throttling here is annoying, I split this up into two to get past the “two URLs only” rule and ran into the “30 seconds between posts” rule

22

Ha! No, spoonjoy.co is an older attempt at building Spoonjoy that’s unrelated, I totally forgot that was up - the .app domain is the correct one, and does use HTTPS :slight_smile:

1 Like
23

I spent so long fighting the platform that I missed your update! Let me catch up.

1 Like
24

Alright, I threw the request data included in the call to https://spoonjoy.app/api/auth into https://debugger.simplewebauthn.dev, and the debugger parsed the JSON just fine, so I don’t think any data is malformed on the front end:

Screen Shot 2022-10-25 at 12.22.51 PM
Screen Shot 2022-10-25 at 12.22.51 PM792×951 121 KB

Which would mean the search should turn towards the logic that receives the request, and what it does with the data before trying to verify it.

1 Like
25

@rob I’m apparently helping too quickly because all of my posts in here were “flagged by the community” as spam. Can you help me out here? I can’t continue to help here if the forums are going to keep treating me like this.

1 Like
26

@IAmKale - I upgraded your membership to trust level 2: member level - hopefully that will help.

It looks like a message or two is still flagged for review. I am not sure if the membership level change will help with further posts.

3 Likes
27

The last place I wanted to suggest starting to debug this is within webauthnRegister(), or whatever logic within Spoonjoy eventually makes the request to this method:

Maybe this is a case of this.event.body being undefined for some reason? That’s the best guess I have for you without seeing any Spoonjoy code (which I’m definitely not asking for access to, to be clear! :joy:) :man_shrugging:

28

Yeah it’s just using this, hm

29

Can you share the Spoonjoy handler that receives the JSON registration body and then attempts to verify it?