Fixes: https://github.com/go-gitea/gitea/issues/36216
Now `detectWebAuthnSupport` returns the error type and lets the caller
decide whether they call `webAuthnError` and show the error. It no
longer shows the error during page load when the user has not even
interacted with the feature.
The bug affects all users on HTTP, so I think a quick fix release for
this might be good.
as you seen, in cureent status `initUserAuthWebAuthn` will prcheck
`window.isSecureContext`, if not ok, will hide the `passkey` btton and
return directly. I think it's not right, first, not show any error
message looks not a good ui, and it's looks will make an empty container
was show if the registion button was disabled also (maybe f-i-x #36115),
then initUserAuthWebAuthn has `window.isSecureContext` check also which
looks duplcate ref:
26602fd207/web_src/js/features/user-auth-webauthn.ts (L202-L206)
so I'd like move hideElem(elSignInPasskeyBtn); to
`detectWebAuthnSupport` failed routs to make it simple and show insecure
error corectly.
Signed-off-by: a1012112796 <1012112796@qq.com>
Co-authored-by: Lunny Xiao <xiaolunwen@gmail.com>
A big step towards enabling strict mode in Typescript.
There was definitely a good share of potential bugs while refactoring
this. When in doubt, I opted to keep the potentially broken behaviour.
Notably, the `DOMEvent` type is gone, it was broken and we're better of
with type assertions on `e.target`.
---------
Signed-off-by: silverwind <me@silverwind.io>
Signed-off-by: wxiaoguang <wxiaoguang@gmail.com>
Co-authored-by: delvh <dev.lh@web.de>
Co-authored-by: wxiaoguang <wxiaoguang@gmail.com>
None of the frontend js/ts files was touched besides these two commands
(edit: no longer true, I touched one file in
61105d0618
because of a deprecation that was not showing before the rename).
`tsc` currently reports 778 errors, so I have disabled it in CI as
planned.
Everything appears to work fine.
