@HLeithner To answer your questions:

1. Yes. It's possible that a 3PD accidentally passes an object and Joomla's caching serializes it. Depending on a few factors this can lead to a permanent and frustrating whitepage for the duration of the user's session. I know it sounds unlikely but as you know I've seen something like that happening and nobody wanted to address it, even in Joomla 4. So the code I contributes defends against stupid instead.

2. Yes, but I'm only trying to fix the architecture here, NOT how the actual code behaves.

3. Yes and no. Look at the HTML code. It's different for the module and com_users' login page. I'd have to create one layout per core extensions. That's why I stopped short of doing that in the original contribution – a point I only remembered after I filed the issue, before I started authoring the PR.

4. I agree. Again, the PR in its original form is the absolute bare minimum of what you can do to fix the architecture. It doesn't fix any functional issues – that requires separate authorization from you or George.

And since I already talked twice about issues I see, here's all the ways that 9d3f7aa fails.

a. WebAuthn is completely broken on a fast localhost because the JS loads before the document object is ready in JavaScript, therefore document.addEventListener fails flat. We should either use async or go back to jQuery.

b. The data attributes are not escaped or processed in any way. We are living on a prayer here.

If you'd like me to fix the functional problems I'll be happy to expand the scope of my PR, as long as you give me the authority to do this. Alternatively, accept this PR to fix the architecture and I'll come back with two separate PRs for each observed issue. If you really want layouts for the buttons I'll do that in the PR for the data attributes issue, killing two birds with one stone.

If you want to proceed the separate PRs route please merge this one and I take full responsibility of it. If something is broken open an issue, at-mention me and I'll drop whatever I'm doing to fix it as a priority issue.

a. WebAuthn is completely broken on a fast localhost because the JS loads before the document object is ready in JavaScript, therefore document.addEventListener fails flat. We should either use async or go back to jQuery.

Run it async

b. The data attributes are not escaped or processed in any way. We are living on a prayer here.

Escape them

more than happy for both those fixes to go into this PR and we can fix all the basics up in one go. My fail on the code review for this. I really should have noticed the escaping. I'd hold everything else we find for future PRs unless it's mission critical.

@nikosdion thanks for the explanations and please follow george comment

The problem is deeper. The script was loaded as defer (which means that DOMContentLoaded event was unnecessary) but the code is all wrong. It's as though the ES6 file was changed blindly, without testing.

First problem: document was bound to the global Joomla object and Joomla was bound to the window object. In both ES6 files. There is not a snowball's chance in Hell that this could have ever worked. Luckily, in the four or so months between contributing WebAuthn and now I sat down and taught myself enough ES6 to understand the problem and be able to fix it.

Second problem: the data attribute on the button is data-webauthn-form but the ES6 code was referencing data-random-form. Not to mention that I personally disagree with both the necessity of having the form name as a data attribute and accessing data attributes as HTMl attributes instead of through the API the browser offers.

I guess I need to do a partial rewrite of the partially rewritten ES6 and have you guys fully re-test the WebAuthn feature because right now it's messed up six ways to Sunday and doesn't even work at all, not it ever had a chance to work with these changes applied. I don't understand what happened here. Charlie didn't test and nobody did either before merging...?

Anyway. I need to not only fix the code but also test with different authenticators and devices. I will ping you when I've gone through the full, very time consuming testing process so you can do the with-whatever-you've-got testing before accepting the PR. That is to say, when you see a commit don't jump into testing just yet. I will ping you when the PR is ready to be tested by you.

@HLeithner @wilsonge This is ready for you to test.

Note: in the User Profile page the user plugin displays the label "Website default" which is kinda dumb. See:

I know how to make it display "No WebAuthn authenticator has been set up yet" or "2 WebAuthn Authenticators already set up: Authenticator Name One, My Other Authenticator". However, this requires adding three language strings and we're in beta freeze. Do you want me to break the rule and add the lang strings or should I leave it like that?

Add the strings please - based on other pr we are not in a language freeze

I think for a language freeze is it too early I would expect a freeze for last beta or rc1 but it will be announced when we go into language freeze separately.

Awesome sauce! Here's the updated PR. I reckon that this (see below for an example) makes far more sense to the user than the previous state ?

I have tested this item ✅ successfully on 95a58cd

Webauthn login still works with Vivaldi 3.0, Firefox 77 and Edge 83, all on Windows 10 with a yubikey. Thanks

@HLeithner Seems you didn't notice that PHPCS failed in Drone when you've tested. Am preparing a PR for @nikosdion with the fix.

Done.

I merged the PR by @richard67 This should now be ready a final test, RTC and merge.

Added back @HLeithner 's test result in the issue tracker since the last change was only PHPCS.

Unfortunately I don't have web authentication set up in any way so I can't quickly test.

Maybe @zero-24 can give it a test? He tested the first implementation once.

@richard67 You can use Chrome and Krypton. See the test instructions in the original WebAuthn PR. It's a software authenticator and it's free of charge. You don't need to have a hardware token to test this :)

@nikosdion Sure, but if @zero-24 still has his stuff ready it would be faster maybe.

Going to merge this on review as testing doesn't seem like it's going to happen anytime soon. And I assume Nik has tested this thoroughly with his own extension

Thank you! Yes, I am testing this every single day, multiple times a day, when I login to my local Joomla 4 development site with GitHub ?