The problem with this approach is that if the server cannot reach the FIDO server (e.g. site behind a firewall, network error, whatever) every call to the service's getKnownAuthenticators will cause another roundtrip to the remote server, the site slows down and possibly times out.

For this approach to work you'd need a flag to indicate if load has been called instead of checking $this->mdsCache.

Moreover, if you have $force you need to go through the loading process anyway, regardless of the flag status.

Just tested unsuccessful

Missed the force flag

Can't we ship the file with joomla? based on the fido alliance website it's updated once a month and changes not too often.

@HLeithner We could. Maybe we could move it inside the plugin and have the build script update it every time we build Joomla?

But I would still lazy load it

@HLeithner We could. Maybe we could move it inside the plugin and have the build script update it every time we build Joomla?

yes updating it in the build process seems to be the best idea. Also websites without internet access would have problems...

@HLeithner However, this would still be half of the problem solved. The other half is that we don't want to decode that massive JWT on every page load. If we are storing this file locally maybe we could instead store a serialised version of the decoded file. Loading serialised data is faster than decoding JWT by several orders of magnitude.

@HLeithner However, this would still be half of the problem solved. The other half is that we don't want to decode that massive JWT on every page load. If we are storing this file locally maybe we could instead store a serialised version of the decoded file. Loading serialised data is faster than decoding JWT by several orders of magnitude.

yes decoding it for faster access makes sense
and only load it if it's really needed as allon said.

@HLeithner Do you want me to try that approach? What @laoneo does is a good band-aid to stop the problem, preloading the file and shipping it with Joomla would be the more permanent solution. Let's divide and conquer.

Agree, we should get this one as fast as possible tested. And also look for more optimization in the long run.

@HLeithner Do you want me to try that approach? What @laoneo does is a good band-aid to stop the problem, preloading the file and shipping it with Joomla would be the more permanent solution. Let's divide and conquer.

yes please.

I don't know if a 4.2.2 will be released soon at least we have a fix here to ship, since it doesn't effect all servers and the plugin can be disabled (not my decision anyway)

if you didnt already see it #38662

I have tested this item ✅ successfully on 59d166b

Closing in favor of #38664.