@nikosdion Does this PR fix #38662 , too?

Yes, it does! Since we no longer go through the network there is no performance penalty when the FIDO server is down.

One performance issue remains, but now it more "local one" so probably not much critical.

Use of json_decode(json_encode($entry->metadataStatement), true).
Because $entry->metadataStatement contain base64 encoded icon, it slows down json_decode, and so whole thing.

@Fedik But it no longer happens on every request. It only happens when you are registering an authenticator or viewing a list of authenticators. In these instances a total page load performance impact between 7 and 30 milliseconds is perfectly acceptable.

Can I suggest we distribute the ability to update the file over CLI too within the CMS as a command. So people can choose to update the local file too? Understand it will always get overridden by update - but feels relatively acceptable.

But it no longer happens on every request.

yes right, that what I meant with: "it now local" :)

@wilsonge If you're on CLI does running something like php /path/to/cli/joomla.php core:webauthn:update make more sense than wget "https://mds.fidoalliance.org" -O /path/to/plugins/system/webauthn/fido.jwt? We really just retrieve and store a file, we don't process it any further.

@Fedik Removing that double encode-decode step will cause fatal errors on PHP 8 with some authenticators. It would also only remove 1-5 milliseconds. Too big a risk for too little gains?

It would also only remove 1-5 milliseconds

Sometimes it hard to stop to make it faster, when see that it can be faster 😄

cause fatal errors on PHP 8 with some authenticators

That interesting.
I would probably then just unset icon (and set it back if it used somwhere in code)

$array = $entry->metadataStatement;
unset($array['icon']);
$array = json_decode(json_encode($array), true);

But it is not related to current PR.

@wilsonge If you're on CLI does running something like php /path/to/cli/joomla.php core:webauthn:update make more sense than wget "https://mds.fidoalliance.org" -O /path/to/plugins/system/webauthn/fido.jwt? We really just retrieve and store a file, we don't process it any further.

On a VM it's fine - in containers it's more complicated because alpine doesn't ship with wget for instance - so having it "php native" can make things easier in some environments.

do we need to add administrator/cache/fido.jwt to the list of files removed on upgrade?

I did not commit the file to the repo, just added a copy statement in the build script to copy it after composer has run. This seems fine to me and less work than committing the file unless you see an issue with that.

@roland-d @nikosdion Does that mean the files is fetched from Fido with every run of composer where it has not rune before or the file has been removed or it is older than 10 days (864000 seconds)? In this case: What do we do if Fido is not reachable when we build a release? In my opinion the file has to be in the repository. Otherwise we still have the problem of creating a DDoS, it's just a bit smaller.

Another thing: Maybe Fido currently is not down but blocked certain user agents or IP ranges due to our DDoS?

P.S.: We have composer install running on quite a bunch of docker images with every single commit of every single PR. If we do not have the file in our sources, we will fetch if every time because the docker images are new for each test. This still might cause them (or their server protection) to block these requests.

@richard67 We talked about that with Harald yesterday, he told me he'd have drone.yaml to create a dummy, empty plugins/system/webauthn/fido.jwt file. This will indeed prevent the script from trying to get a new file which means the PR builds will work fine without hitting the FIDO server.

P.P.S.: Ah, wait,. it's only fetched when packages are built ... so less critical ... but I still think it should be in the sources.

I was told it would be taken care of. I don't use Drone, I am a Luddite who runs his tests locally :) (Between travelling a lot before Covid-19 and having unreliable Internet more often than not when I'm back home it's actually the only way for me to make sure I can run my tests without frustration).

Well maybe I am wrong and there is no problem, and I just did not understand it on the first look.

Regarding testing: I can test the performance thing, but I can not test if webauthn with Fido is still working (which in my opinion should be tested, too) because I have no Fido key.

The WebAuthn part still works but it'd be great to have some people with Windows computers to test Windows Hello. Maybe @brianteeman if he's not super busy?

@nikosdion As we do not have any other deleted files and folders from 4.2.1 to 4.2.2, I've decided to make a PR for you to make that change in script.php here in your PR: https://github.com/nikosdion/joomla-cms/pull/11

This will save the release lead one PR to be merged.

If you don't want that, let me know, and I will make a separate PR for that in this repo here.

Thank you, Richard! I just merged it :)

Thanks Nik.

I have tested this item ✅ successfully on a66514a

I have updated a 4.2.1 site (copy of my 3.10 homepage once updated to J4 for development) on my domain to the custom update URL provided by drone for this PR.

I could successfully verify that the performance problem is fixed by this PR.

In addition I have successfully tested that Webauthn still works as primary login authenticator and as MFA factor and both together. I have used Windows Hello with a PIN on my computer and Firefox latest stable.

I have tested this item ✅ successfully on a66514a

I was able to test it successfully on multiple websites and different hosts.

RTC

Thank you

Thanks for fixing this guys lol.

If you ever have deployment issues and help with FIDO in general: ackermann.yuriy@gmail.com.