Fix bugs with WebAuthn preventing sign in and registration.

[zeripath]

This PR fixes two bugs with Webauthn support:

• There was a longstanding bug within webauthn due to the backend using URLEncodedBase64 but the javascript using decoding using plain base64. This causes intermittent issues with users reporting decoding errors.
• Following the recent upgrade to webauthn there was a change in the way the library expects RPOrigins to be configured. This leads to the Relying Party Origin not being configured and prevents registration.

Fix #22507

Signed-off-by: Andrew Thornton [email protected]
Co-authored-by: wxiaoguang [email protected]

[zeripath]

Alternatively I have raised an issue on WebReflection/uint8-to-base64#1 which may result in an update to the package there and we could use that instead if preferred.

[zeripath]

There may be another way of making webpack make this work too.

[wxiaoguang]

See:

• Login with security keys no longer possible #22507 (comment)
• Demo for Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded. #22654

[lunny]

per @wxiaoguang 's comment

[lunny]

It's still error when register a new security key.

2023/01/30 09:27:11 ...security/webauthn.go:83:WebauthnRegisterPost() [E] [63d71cef] Unable to finish registration due to error: Error validating origin
	DevInfo: Expected Values: [], Received: https://localhost:3000
2023/01/30 09:27:11 ...security/webauthn.go:85:WebauthnRegisterPost() [E] [63d71cef] CreateCredential: Error validating origin
2023/01/30 09:27:11 ...s/context/context.go:219:HTML() [D] [63d71cef] Template: status/500
2023/01/30 09:27:11 ...user/notification.go:45:func1() [I] [63d71cef] [SQL] SELECT count(*) FROM "notification" WHERE (user_id = $1) AND (status = $2) [3 1] - 12.352889ms
2023/01/30 09:27:11 [63d71cef] router: completed POST /user/settings/security/webauthn/register for [::1]:55056, 500 Internal Server Error in 45.6ms @ security/webauthn.go:62(security.WebauthnRegisterPost)

[wxiaoguang]

Yup, that's why I said in my demo PR: "After: The dialog can be displayed.", but not "It works". Because it still doesn't work ....

I just doubt that whether any one has really tested it.

I am glad to see the error is the same now: "Error validating origin" (my is on https://production, when login with an existing webauthn)

[lunny]

Yup, that's why I said in my demo PR: "After: The dialog can be displayed.", but not "It works". Because it still doesn't work ....

I just doubt that whether any one has really tested it.

I am glad to see the error is the same now: "Error validating origin" (my is on https://production, when login with an existing webauthn)

Looks like, even revert #22400 , the error is still there.

[wxiaoguang]

It also needs this to make webauthn (new lib) work (the reason is complicated, so keep this comment simple)

Usually, it needs webauthn.New() to create a new Config.

The new webauthn libs deprecated the RPOrigin field, and webauthn.New() can append RPOrigin to RPOrigins.

But Gitea doesn't call webauthn.New(), then the RPOrigins is empty

I have tested it with my demo PR on my side, I can login with webauthn.

diff --git a/modules/auth/webauthn/webauthn.go b/modules/auth/webauthn/webauthn.go
index d08f7bf7c..937da872c 100644
--- a/modules/auth/webauthn/webauthn.go
+++ b/modules/auth/webauthn/webauthn.go
@@ -28,7 +28,7 @@ func Init() {
                Config: &webauthn.Config{
                        RPDisplayName: setting.AppName,
                        RPID:          setting.Domain,
-                       RPOrigin:      appURL,
+                       RPOrigins:     []string{appURL},
                        AuthenticatorSelection: protocol.AuthenticatorSelection{
                                UserVerification: "discouraged",
                        },

[wxiaoguang]

Maybe it could be encodeURLEncodedBase64 like decodeURLEncodedBase64

[zeripath]

done

[zeripath]

I just doubt that whether any one has really tested it.

This definitely used to work and was tested thoroughly.

[zeripath]

Thanks for the RPOrigins thing - that explains the sudden breakage!

[james-d-elliott]

Let me know if I can assist in any way with this, regarding the javascript I'd recommend @simplewebauthn/browser.

[zeripath]

Make lgtm work

[yardenshoham]

Can't really backport without #22400

[yardenshoham]

Do these bugs exist in v1.18? Maybe we don't have to backport

[delvh]

They shouldn't exist on 1.18.
As I said on the issue, I can still log in without a problem to a private 1.18 instance.
The problem appears to be mainly due to the upgraded library, and the illegal behavior was probably ignored previously.

[delvh]

The only thing I am somewhat afraid is that logins that were previously valid suddenly stop being valid…
After all, the output sent to the server is now different?

[zeripath]

Nah, the output sent is the same - it's the response received by the js that is different and those that are different would have previously caused spurious errors.

This PR does fix some another issue that was not related to the upgraded library so there will need to be a partial backport primarily of the JS changes only (skipping the RPOrigins stuff). I should be able to get that done tonight.