[#38662] - 5 seconds delay on J4 sites with Webauthn plugin enabled
- Closed
- 1 Sep 2022
- Medium
- Build: 4.2-dev
- # 38662
Steps to reproduce the issue
Multiple reports today of this, on Facebook Joomla group, with J! 4.1.5, 4.2.0 and 4.2.1. I can reproduce on a couple of sites and not on another one (see below).
Expected result
Normal page load times with Webauthn system plugin enabled.
Actual result
An extra 5 seconds is needed for all page loads. Disabling the plugin solves the issue.
Additional comments
I suspected this was due to some remote server not being available, so I traced that back quickly to line 150 of j4/plugins/system/webauthn/src/MetadataRepository.php:
The plugin tries to load a JWT from https://mds.fidoalliance.org/, with a 5 seconds time out, if the one in cache is more than one month old. In case the request fails, it's supposed to write an empty string to the file, preventing repeated requests.
It's that mechanism which does not work. The empty string is only written to disk if:
if (!empty($content) || !file_exists($jwtFilename) || filesize($jwtFilename) <= 1024) {
file_put_contents($jwtFilename, $content);
}
As $content is empty and the $jwtFilename does exist, the condition to write back to file is that filesize($jwtFilename) <= 1024 but the actual filesize is already - on my local machine at least - 1,468KB.
As such the file is not written to disk and the attempt to reach the server is made on each page load. I suspect the condition is the opposite, filesize($jwtFilename) > 1024 and using such condition does fix the issue for me.
Votes
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-09-01 09:09:15 |
| Closed_By | ⇒ | HLeithner |
Yes sure, different issue.
@HLeithner this should stay open as it is a different issue.
| Status | Closed | ⇒ | New |
| Closed_Date | 2022-09-01 09:09:15 | ⇒ | |
| Closed_By | HLeithner | ⇒ |
ah empty file ok sorry
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)
The problem in this issue does need a faster fix than the one in #38654, and may warrant a 4.2.2 release. As the webauthn plugin is enabled by default, I reckon a large part of all Joomla 4 sites have an extra 5 seconds load time today.
Disabling the plugin is a fix, if you actually know that you have to do that.
same issue here. thought it was the server until i found this..
@HLeithner of course, he fido alliance server is likely going to go back up soon, and the problem will disappear so we may also just wait, assuming it'll take more time for us to make a release than for them to fix the issue?
By the way, the server is not down, it's just slow: took 10 seconds for me to download the file on my local desktop machine.
recording of various errors that happen when you try to log in using webauthn and the fido file is empty
chrome_oQ2jK2SJx2.mp4
By the way, the server is not down, it's just slow: took 10 seconds for me to download the file on my local desktop machine.
your lucky - no data downloaded at all for me
May be the fido alliance server is suffering from all requests by the joomla websites?
Same Issue here with 4.2.1, the admin and frontend are fully unusable, every click we have a wait 5 or more seconds.
This can lead big problems with website positioning in search engine.
"System - WebAuthn Passwordless Login" Plugin Disabled
"System - WebAuthn Passwordless Login" Plugin Enabled
@simbus82 The problem is well identified now, the best fix is being discussed here and in #38654. Until it is fixed properly, disabling the plugin does fix it as well.
Can be pushed a message/plugin update about this info to every J4.2.1? Or is needed a new full release?
Not all people follow github or the joomla.org website or social channels. I think it's very urgent to communicate this problem.
@simbus82 Depends on how fast a release can be but there's no way to push a message to all J4 users aside from Joomla website and social networks.
Side note: don't think the above fix will work in all cases.
if (!empty($content) || !file_exists($jwtFilename)) {
file_put_contents($jwtFilename, $content);
}
if (empty($content) && filesize($jwtFilename) > 1024) {
file_put_contents($jwtFilename, $content);
}
should work better.
I dont understand is if its illegal in germany and elsewhere to use google fonts just in case they log the ip (even though they say they dont) how can it be ok to load this file from the fido alliance?
I dont understand is if its illegal in germany and elsewhere to use google fonts just in case they log the ip (even though they say they dont) how can it be ok to load this file from the fido alliance?
The connection to Google Fonts is made via the user agent (browser), the IP ends up at the destination of the HTTP call, for example at Google.
In this case, however, the connection is not made via the UA, so the IP of the UA does not end up there either, unless personal data is transferred in the content of the request.
thank you for the explanation
I dont understand is if its illegal in germany and elsewhere to use google fonts just in case they log the ip (even though they say they dont) how can it be ok to load this file from the fido alliance?
The connection to Google Fonts is made via the user agent (browser), the IP ends up at the destination of the HTTP call, for example at Google.
In this case, however, the connection is not made via the UA, so the IP of the UA does not end up there either, unless personal data is transferred in the content of the request.
Ehm, no.
Every call, get, etc or TCP/IP leave a caller IP in the log, so in Fido Alliance (California) they have all IPs of every Joomla installation that download the JWT.
@simbus82 Yes, but that's the IP of the server, owner and creator of the website, not the IP of the website visitors
You are right, it's only our server ip. But if it is a private local server, i'm transferring my personal data to US anyway without knowing it (my server ip it's my "home" ip, so it's my geolocation), and i'm the user of a extra-EU service (fido jwt). I know, it's ridicolous, but it's the paradox of GDPR. :-(
You are the producer of the electronic system. The GDPR does not apply to you, it applies to the "consumers" of your public facing website.
In my eyes, the GDPR is very logical
richard67
- | Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-09-01 11:29:23 |
| Closed_By | ⇒ | richard67 |
It depends on situation:
-
If the website is located on a shared hosting, the IP of that server is transferred. No issue with GDPR.
-
If I run my Joomla website on a local server within my home network, the IP is that of my router. Issue with GDPR.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/38662.
It depends on situation:
*> * If I run my Joomla website on a local server within my home network, the IP is that of my router. Issue with GDPR.
Not an issue with GPDR
that exactly describes my findings as well