[#25797] - [4.0] W3C Passwordless Web Authentication (WebAuthn)
- Closed
- 8 Aug 2019
- Medium
- Build: 4.0-dev
- # 25797
- Diff
- nikosdion:feature/webauthn
- Pending Hound Hound is busy sniffing around... Details
User tests: Successful: Unsuccessful:
Pull Request for new feature: passwordless authentication with W3C Web Authentication (WebAuthn)
Summary of Changes
This PR adds support for WebAuthn (W3C Web Authentication). This is a W3C standard made official in March 2019.
WebAuthn allows users to authenticate (log in) securely into a site without using a password. Instead it uses authenticators. An authenticator is either a discrete hardware device or a Trusted Platform Module (TPM) / Secure Enclave built into your device. Moreover, it only works under HTTPS. By using secure hardware and secure transport it makes sure that the authentication is resistant to eavesdropping, phishing, brute-force and other attack modes associated with fixed passwords.
Before continuing please take a minute to learn more about WebAuthn and play with it.
Testing Instructions
i. Requirements
Your site must be using HTTPS with a certificate your browser recognizes as valid. For simplicity's sake, please use a live server with a valid SSL certificate, e.g. one issued by Let's Encrypt.
An authenticator. A FIDO or FIDO 2 compatible hardware key is the best. Some computers and browsers may be able to use biometric sensors. You may also use a software FIDO key such as Krypton. Yours truly has used a YubiKey Neo (FIDO over USB and NFC), a Security Key NFC by Yubico (FIDO 2 over USB and NFC) and Krypton (FIDO over Bluetooth / browser extension).
WebAuthn compatible browser. Not all browser versions are compatible with WebAuthn. If unsure, check if you can use the WebAuthn.io site with it BEFORE trying to test this PR. At the time of this writing no browser on iOS will work with WebAuthn, Safari is mostly broken and Chromium-based browsers (except Chrome itself) do not work with Touch ID on macOS. Your best bet is Google Chrome and Firefox on desktop operating systems or Android.
ii. Enabling the plugin
Go to Plugins and enable the “System - WebAuthn Passwordless Login” plugin.
iii. Perform basic tests
Please conduct the following tests in the following order. If something doesn't work please first read the FAQs below.
If your solution is not there first check if the same combination of operating system, browser and authentication work with the webauthn.io site. If not, the problem is between your OS, browser and authenticator. It is not a bug in the plugin and cannot be magically fixed.
If you could not find an answer in the FAQs and your authenticator worked with webauthn.io please provide the following information:
- URL to your site, including the scheme. Example: https://www.example.com
- Database type and version. Example: MySQL 5.7.26
- Your username. Example:
foo_Bar - Operating system and version. Examples: macOS 10.14.5, iOS 12.1, Ubuntu Linux 18.04.01
- Browser make and exact version. Example: Safari 12.1.1 (14607.2.6.1.1)
- Authenticator used. Example: YubiKey 4
- Authenticator connection method. Examples: USB-A, USB-C, USB-A with Lightning-to-USB adapter, Bluetooth, software
- Does the same combination of operating system, browser and authentication work with the webauthn.io site? If not please do not file a failed test report; the problem is somewhere between your OS, browser and authenticator, not Joomla itself.
Test 1: Login Buttons
Log out from your site's frontend and backend.
Go to your site's frontend home page and look at the login module. You should see a “Web Authentication” button under the Remember Me checkbox.
Go to your site's frontend user page (/index.php/component/users/login). You should see a “Web Authentication” button under the Remember Me checkbox.
Go to your site's backend page (/administrator/index.php). You should see a “Web Authentication” button under the Remember Me checkbox.
Test 2: WebAuthn can't be used if you haven't registered an authenticator
Log out from your site's frontend and backend.
Go to your site's frontend home page and locate the login module.
Type your username but NOT your password.
Click on the “Web Authentication” button.
Expected: an error message that the username does not exist or is not linked to WebAuthn.
Test 3: Register an authenticator from the backend
Log in to your site's backend using your username and password.
Go to Users, Manage and click on your username.
Click on the “W3C Web Authentication (WebAuthn) Login” tab.
Click on the big, green “+ Add New Authenticator” button and interact with your authenticator. Please note that the prompt to interact with your authenticator is specific to and rendered by your browser.
Expected: You see a new authenticator appearing on the list above the green button. There is no need to click on “Save & Close”; the authenticator assignment is (and has to be, for seriosu security reasons) saved during the previous interaction.
Test 4: Rename an authenticator
Log in to your site's backend using your username and password.
Go to Users, Manage and click on your username.
Click on the “W3C Web Authentication (WebAuthn) Login” tab.
Find the authenticator you created before and click the “Edit Name” button next to it.
Expected: The name becomes and editable text field with a Save and Cancel button next to it.
Click on “Cancel” next to the text field.
Expected: the old name remains.
Click the “Edit Name” button again. This time enter a new name and click on “Save” next to the text field.
Expected: the new name sticks.
Test 5: Delete and authenticator
Log in to your site's backend using your username and password.
Go to Users, Manage and click on your username.
Click on the “W3C Web Authentication (WebAuthn) Login” tab.
Find the authenticator you created before and click the “Remove” button next to it.
Expected: the authenticator is gone.
Also repeat test 2 and make sure you still get the expected message.
Test 6: Repeat tests 3, 4 and 5 for the frontend
Log in to your site's frontend using your username and password.
Go to the user profile editor page (/index.php?option=com_users&view=profile). Please note that if you try using Joomla's sample data menu items such as Your Profile it won't work. This is a bug in the sample data that has nothing to do with this PR (I confirmed it happens with a from-scratch installation of the current Joomla! 4 development branch).
Click on the Edit Profile link at the top right of the main content area and find the “W3C Web Authentication (WebAuthn) Login” area towards the bottom of the page's content area.
Perform tests 3, 4 and 5 replacing the first three instructions of each test with Test 6's first three instructions.
Test 7: Log into the frontend, mod_login
Perform test 3 again. You will now have an authenticator registered for your user account.
Go to the frontend of your site and locate the Login module.
If you are already logged in please click on Logout to log out of your site.
Enter your username but NOT your password.
Click on the “Web Authentication” button in the Login module.
Expected: your browser asks you to interact with your authenticator. Please note that the prompt to interact with your authenticator is specific to and rendered by your browser.
Interact with your authenticator as requested.
Expected: you are logged into your site's frontend.
Test 8: Log into the frontend, com_users
Make sure you have an authenticator registered for your user account. If not, perform test 3 again.
Go to the frontend login page (/index.php/login). Please note that if you try using Joomla's sample data menu items it won't work. This is a bug in the sample data that has nothing to do with this PR (I confirmed it happens with a from-scratch installation of the current Joomla! 4 development branch).
If you are already logged in please click on Logout to log out of your site.
Enter your username but NOT your password.
Click on the “Web Authentication” button in the Login module.
Expected: your browser asks you to interact with your authenticator. Please note that the prompt to interact with your authenticator is specific to and rendered by your browser.
Interact with your authenticator as requested.
Expected: you are logged into your site's frontend.
Test 9: Log into the backend
Make sure you have an authenticator registered for your user account. If not, perform test 3 again.
Go to the backend login page (/administrator).
If you are already logged in please log out now.
You should be seeing the backend login page now.
Enter your username but NOT your password.
Click on the “Web Authentication” button in the Login module.
Expected: your browser asks you to interact with your authenticator. Please note that the prompt to interact with your authenticator is specific to and rendered by your browser.
Interact with your authenticator as requested.
Expected: you are logged into your site's backend.
Test 10: Using multiple authenticators (OPTIONAL)
Repeat test 3 as many times as necessary to attach multiple authenticators to your Super User account.
Repeat tests 7, 8 and 9 once for each authenticator you have registered. You should be able to log into your site with any of your authenticators.
Important! Not all authenticators are supported in all browsers. For example, you may register a Krypton software authenticator and a Touch ID / Windows Hello / biometric authenticator using Chrome but you won't be able to use either using Firefox for example. This is NOT a bug in the PR; it's a browser limitation. The idea behind registering multiple authenticators is that you may actually need to have multiple physical authenticators to support all your devices e.g. Touch ID for your work MacBook Pro, a USB hardware key for your personal desktop PC and an NFC hardware key for your Android device. If it wasn't for this much-needed flexibility we'd only allow a single authenticator per user account.
Backwards compatibility
As far as I can reasonably tell, this PR does not adversely affect backwards compatibility.
It should be noted that login modules will require to support the onUserLoginButtons event for user plugins to ensure full compatibility with Joomla 4 and the WebAuthn feature. However, any module not supporting this new feature will still work without any adverse effects.
Finally, com_ajax is available in the backend login page with no authenticated user. If there are any insane developers out there who assume that a com_ajax request in the backend of the site means that someone is logged in should change their code and reconsider their life choices because, frankly, this is a sign of not knowing what they're doing. Always use Factory::getApplication()->getIdentity() to get the currently logged in user to figure out if it's logged in and which permissions it has.
Translation impact
A new plugin was added which requires translating the following files:
- administrator/language/en-GB/en-GB.plg_system_webauthn.ini
- administrator/language/en-GB/en-GB.plg_system_webauthn.sys.ini
Documentation Changes Required
The plugin itself as well as two smaller core but backwards compatible changes implemented will need documentation.
Extra login buttons
The plugin module and com_users now use the onUserLoginButtons event, defined and called in Joomla\CMS\Helper\AuthenticationHelper::getLoginButtons, to retrieve the definitions of any additional buttons which need to be placed after the regular login button.
All developers implementing a login module or, more generally, a login form should also use the Joomla\CMS\Helper\AuthenticationHelper::getLoginButtons public static method to retrieve said definitions and render these buttons to make their software fully compatible with Joomla 4.
Developers wishing to implement custom buttons should look at how the WebAuthn system plugin implements this functionality. Such buttons can be used for implementing third party single-sign-on services or even logging in using third party identity services such as those offered by popular social media (Facebook, Google, Twitter, GitHub etc).
This change does not adversely impact backwards compatibility. Third party login modules and login forms will continue functioning normally even if they do not implement the extra login buttons feature with the notable omission of integrations afforded by said feature such as Web Authentication itself. That is to say they won't stop functioning (which would be a b/c break) but they won't be feature-complete. Therefore the impact is much more benign that, for example, that of not including the Two Factor Authentication's Secret Code field back in Joomla! 3.2.
Allowing com_ajax in the backend login page
Throughout Joomla! 3 com_ajax was limited to logged in and guest frontend users, as well as logged in backend users. This PR whitelists com_ajax in AdministratorApplication so it can be used to handle requests by guest users viewing the backend login page.
This change does not cause any backwards compatibility issues as long as developers use sane practices and do not assume that being called by com_ajax in the backend is proof that the user is logged into the backend. That would be a bad security practice. The sane practice is to use Joomla's User object to detect if it's a guest user and if not whether the user is allowed a permission required to effect the action requested through com_ajax. That is to say, if this change broken your code then your code was already broken six ways to Sunday and needed to be reworked anyway. You are welcome for the unexpected security audit :)
The WebAuthn plugin itself
Obviously someone other than me needs to write some documentation for this plugin. A good idea would be to base it off the tests and information I include in this PR, especially the FAQ that follows. Someone who can translate engineer-speak to user-speak would be fantastic for this task :)
Frequently Asked Questions (FAQ) and Further Information
I can't see the “Web Authentication” login button
You are not accessing your site under HTTPS. WebAuthn is only available for HTTPS sites with a valid certificate. This is a security precaution baked into the WebAuthn standard. The plugin actually checks if the site is accessed through HTTPS using Uri (the former JUri class). In rare cases where the server lies about the protocol you might not see the button even though your site (claims to be) HTTPS. However, I'd argue that if your SSL terminator doesn't inform your web server that the site is being accessed through HTTPS you have a major security issue with cookies and you should fix it instead of complaining about this PR not rendering the WebAuthn button (hint hint wink wink).
Also note that third party login modules and components implementing their own login form will not display these buttons just yet. We added new infrastructure to support them, much like what we had to do in Joomla! 3.2 to support Two Factor Authentication.
I still need to provide a username. Isn't WebAuthn supposed to get rid of usernames?
Yes and no. The current implementation in browsers only allows authentication, not identity validation. The future plan for WebAuthn is to allow FIDO 2-compatible authenticators to also provide the identity of the user, eliminating the need for supplying a username. The full spec also has some nifty extra security features, like pinning authenticators to specific TLS certificates to prevent man-in-the-middle attacks with certificates issued by user-installed CAs such as those installed by corporate policies and surveillance states... but I digress. These are all features which will be implemented by browsers in the future. When will that happen? It's anybody's guess. When this happens I'll try to contribute the necessary code to support identity validation. Caveat: it will probably require updating the Composer dependency for the underlying library so it won't be until Joomla 5 or until someone sees how absurd this "don't upgrade anything because semver" is for internal dependencies. But I digress again.
I have registered an authenticator but trying to log in tells me that I haven't. Is this a bug?
It is a bug but not with the plugin itself. One or more plugins on your site throw PHP Notices, Warnings or Errors, thus corrupting the reply sent back by your server. As a result the JavaScript on the page cannot parse the server response and is unsure whether any authenticators are registered by the user.
Go to your site's backend, System, Global Configuration and set Error Reporting to None. In most cases of misbehaving core and 3PD plugins this is enough. Otherwise please examine the output of the request using your browser's developer tools to see what is corrupting the request.
There is no prompt on Safari to use my authenticator
This is a Safari bug. At the time of this writing Safari's support for WebAuthn is an experimental feature and not quite finished. In my tests it also only works with USB hardware keys (FIDO and FIDO 2).
I am trying to use this on Safari but it displays a weird message about a request pending
This is another Safari bug. Close your browser (CMD-Q) and restart it. In most cases it will work. If you've registered more than one authenticator it will still not work properly. As explained above, at the time of this writing Safari's support for WebAuthn is an experimental feature and not quite finished.
I cannot use a biometric sensor (TouchID, fingerprint, Windows Hello)
Only Google Chrome on a limited number of platforms correctly supports built-in authenticators with biometric security. Chrome-derived browsers such as Opera or Brave will ask you if you want to use a built-in sensor but will promptly crash when you select this option. Other browsers such as Firefox and Safari won't even offer this option. This is a limitation of the browsers and cannot be worked around.
If you are using Windows please remember that your device MUST have a Trusted Platform Module (TPM) chip and it must be enabled in the BIOS. Just having a Windows Hello-compatible biometric sensor won't do the trick. This is a security precaution in the WebAuthn standard itself: the authenticator information must be processed using secure, tamper-resistant hardware to prevent key subversion (e.g. malware running on the computer cannot steal the key used for authentication).
Also, please do remember that WebAuthn is still a very new standard. By the time Joomla 4 is released browsers will have progressed far enough to make WebAuthn more usable for the average user. We are currently experiencing the bleeding edge of secure logins as it's being developed.
If I can use a software authenticator why should I bother with a hardware token?
The linchpin of WebAuthn is the absolute secrecy of the private key. It is only known to the authenticator and it should be impossible to communicate to the outside world.
In the case of a hardware authenticator, be it a discrete hardware device or a TPM / Secure Enclave, this is a given. The secret key cannot be retrieved; there is no such functionality in the hardware. Moreover, the hardware itself is tamper-resistant, making it extremely difficult retrieving the secret key and only be performing very complicated, very expensive and destructive analysis (or someone found a security hole in the secure operating system of the hardware key / TPM and coaxed it to spill its secrets, an attack which at the time of this writing is entirely theoretical and has never been demonstrated). Not to mention that you'll probably notice that your hardware key or device got lost or stolen.
A software authenticator generates and stores a secret key. However, it is still a regular software application which runs inside your regular operating system, be it your phone's or your computer's. As a result it is susceptible to several classes of attacks which can be used to surreptitiously steal information (security issues in the software itself, malware using Spectre-class vulnerabilities in modern CPUs etc).
So, a software authenticator is far more convenient and secure than a regular password but a hardware authenticator offers the best security, hands down. Choose your authenticator based on your budget and security needs.
I'll try to give a rule of thumb here. Use a software authenticator for sites like your blog or company presentation site which really store little to no secrets. The software authenticator is a step up from password authenticator and will protect you from most real world password stealing attacks. If your site contains trade secrets, client information, manages large sums of money or otherwise is a fat, juicy target for attackers who will bother going after you with advanced, targetted hacking methods then do yourself a favor and use a hardware authenticator. In this case also make sure you use 64+ character passwords and hardware-based Two Factor Authentication to prevent brute force attacks. If your security needs are higher than that... let's just say that you need something entirely different.
Why are the credentials encrypted in the database? Isn't this an overkill?
The only thing stored in the database is the public key returned by the authenticator when we are performing the registration ceremony (that's what the W3C specification calls it). Being a public key it does not need protecting from reading. Even if an unauthorised user was able to read this information they would not be able to impersonate the authenticator e.g. by cloning it.
However, if a malicious user had write access just to the #__webauthn_credentials database table, without read access to the filesystem and without write access to any other table, they could conceivably insert their own authenticator therefore impersonating a targeted user on the system. This is a very theoretical attack since they would also need to know the user handle for the user they are attacking. Besides, having write access to just this table and not the entire database (in which case they could create a new Super User) is extremely unlikely. Still, we are encrypting the credentials to make it impossible for even this entirely theoretical attack to succeed.
I am fully aware that if a user has read access to the filesystem they have access to the encryption key and the database connection information, all of which is stored in configuration.php. However, in this case you are already hacked: the attacker can read configuration.php therefore they know how to connect to your database. In this case they can do whatever they please to your site, including deleting all existing Super Users and creating their own Super User account. Therefore there's no reason to try to address this situation; you'd be fully pwned. The only that could save you is regular, tested, off-site backups.
I have set up Two Factor Authentication but I am logged in without providing my Secret Key. Isn't this insecure?
No, it's intentional and by design.
When I contributed Two Factor Authentication (TFA) in Joomla! 3.2 you were only able to log into your site using a username and password. Passwords can be stolen or guessed. Therefore TFA was the only way to provide a modicum of security on high risk and high value targets.
WebAuthn is an entirely different beast. It uses strong cryptography and secure hardware to make it practically impossible to subvert the authentication cryptographic keys (so far nobody has a proven ability to compromise hardware security keys and trusted hardware modules as explained above). As a result, authentication with WebAuthn is incredibly secure and supersedes the reasons that necessitated TFA. Therefore, if you successfully authenticate using WebAuthn the TFA secret key is not checked at all.
You should use both WebAuthn and TFA on your account for maximum security. WebAuthn is an additional way of logging into Joomla, not the only one. Password authentication is still allowed. Therefore someone can still guess or steal your password just like they could do back in 2012 when I contributed TFA to Joomla. TFA will protect your password authentication. WebAuthn allows you to NOT use a password for everyday use, making it far less likely that your password will be stolen.
Finally note that if we want to implement multifactor authentication for Joomla we should be looking into replacing TFA with Two Step Verification. The difference is that TFA requires you to provide your second factor together with the login information, making it impossible to use asynchronous second factors such as email codes, text messages, U2F etc. With Two Step Verification you log in but instead of being logged into the site you're in a “captive login” state. The only thing you can do is select which second factor you want to use. This is far more secure and that's what major tech companies such as Microsoft, Google, Apple and Facebook use. If we really want to go that route I have already proved this work with a real world, free extension I could always contribute to Joomla 4.
Isn't TFA good enough? Why do we need WebAuthn?
TFA is good enough in most cases but suffers from two issues.
First, it has a rather awkward user experience. You need to provide your ever-changing secret key with your username and password. Most people use TOTP (the six digit PIN that changes every 30 seconds) which slows down logging in and tends to frustrate users. Using a YubiKey is much faster but also expensive and more complicated to provision.
Second, if you are using TOTP you are susceptible to security issues such as keyloggers, phishing and the possibility that the secret key used for generating the TOTP is stolen. Moreover, with one million possibilities and thirty seconds to try them it is conceivable that an attacker can get lucky since Joomla doesn't lock your account or otherwise employ rate limiting for failed login attempts. While these protections could be implemented, the implementation itself could be abused to create a denial of service situation which locks a legitimate user out of their site while the attacker is busy infiltrating it. It's a double edged sword.
WebAuthn marginally improves the user experience but I'd rather withhold judgement until major browsers solidify their implementation of the specification. Currently the smoothest user experience is using Chrome on macOS with Touch ID. Enter the username, click a button, put your finger on the sensor and you're in. Using a miniature FIDO key permanently inserted into the USB port of a laptop is also just as smooth: username, click a button, put your finger on the key's sensor and you're in. Mobile devices still have a terrible user experience way too many taps and confusing text, or they don't work at all (iOS, I am looking at you!).
Where WebAuthn is killing it is at the security front. By virtue of using secure hardware and strong validation of the site's domain name it is practically immune to keyloggers, phishing and key subversion. It even has built-in protection against key cloning. Yes, you can still lose your hardware or have it stolen but the same goes with your house keys.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Repository SQL Administration com_admin Postgresql Language & Strings Modules NPM Change JavaScript Front End com_users External Library Composer Change Installation Layout Libraries Plugins |
franz-wohlkoenig
- | Title |
|
||||||
| Labels |
Added:
?
?
NPM Resource Changed
?
|
||
Sorry, I don't have infinite time to play around with reformatting JavaScript and waiting for an automated tool to tell me if it's pleased. I have real work to do. I am afraid that if you have an automated tool ask me to waste my time I cannot contribute to this project. Write better instructions and tools to fix trivial issues such as code formatting if you want to keep contributors around.
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2019-08-08 14:12:18 |
| Closed_By | ⇒ | nikosdion |
This looks like a great step forward thanks for this PR
@zero-24 I am aware of how important this feature is (I wrote the PR description myself) and I'm aware how sad it is that I can't contribute because the Joomla project failed to provide a sensible set of contribution guidelines.
No, I do not want the Joomla project to steal my code and my hard work because the Joomla project itself failed to disclose there is a JavaScript coding standard, does not provide a human readable definition of the coding standard, does not tell developers how to check their code against this coding standard, does not have any documented way of applying this coding standard automatically and nevertheless requires compliance with this coding standard to contribute.
What I really want is a way to fix the JS code style validation errors. Can you please give me one that doesn't require me to spend an inordinate amount of time fiddling with spaces just to appease a darned tool? Does this project still care about delivering value to the user or has it devolved into Tool Appeasement Driven Development?
@wilsonge basically told me on Twitter to use npx eslint --fix FILE and npx eslint PATH. Here are some thoughts on the results.
The code style asks me to change for (let i = 0; i < elForms.length; i++) { to for (let i = 0; i < elForms.length; i += 1) {. I don't consider this more readable in any stretch of the imagination. There's a precedent of using the former form the last 40-odd years, since C was invented.
The --fix parameter converts the code to an inscrutable form that's impossible for non-hardcore JS developers to read. After this conversion I have no idea what the code I wrote myself does. If you were to ever ask me to debug it or make a change I'd be unable to help.
ESLint complains that a function is used before it's defined. It's essentially a help function I put at the end of the file because it's far less important than the function that is called to perform the login. Yet the linter DEMANDS that I put it on top, making the purpose of the file harder to understand.
ESLint complains that my plgSystemWebauthnLogin function is not used and considers it an error. This method is actually called when you click on a button element. Therefore no matter what I do my code will always appear to be erroneous UNLESS I add a useless file that is not included anywhere and does nothing except have calls to the functions I only ever call through clickable UI elements. This is idiotic and does not help with clarity.
ESLint does not let me check if a function parameter is null / undefined and assign a default value on it. So instead of this:
function plgSystemWebauthnInterpolateParameters(object, prefix) {
const prefix = prefix || '';I have to do this
function plgSystemWebauthnInterpolateParameters(object, thisParamIsThePrefix) {
const prefix = thisParamIsThePrefix || '';I do not think that anyone in their right mind would consider the latter code to be "better" unless "better" is a synonym for "braindead".
ESLint does not let me use a for-loop to iterate an object's parameters. Unfortunately, I am not a hardcore JS developer and I do not understand WTF it wants me to do instead. Since this is an error my code will never be clear unless I spent an unknown amount of time trying to understand what it wants me to do.
ESLint does not let me use console.log. If I remove this good luck trying to help any real world Joomla user having trouble using WebAuthn considering that the JS we ship is transpiled and minified. As a result it will forever be an inscrutable black box.
ESLint does not let you do a try-catch where the catch portion does not use the exception object caught. I use that pattern to provide a user-friendly error message instead of the asinine browser default messages. I can of course remove that functionality to appease the Hound but it will be to the detriment of the user.
Based on the above I decided to NOT contribute this feature to the project. I was trying to provide an important security feature in a user-friendly manner.
The Joomla project has added a very high artificial barrier to contributions containing JavaScript code. Instead of writing simple, jQuery-based code that anyone can read you demand that we write very complicated, terse and inscrutable JS code aiming to appease a JS coding standard created by a multi-billion dollar company with dedicated JS developers. Having seen the code before and after appeasing the tool (even just to a certain extent) I can't help but notice that the original code could be understood by everyone and worked well whereas the "fixed" code cannot be read even by the person who wrote it and does NOT work at all (for what reason I don't know because I can't bloody read it anymore!). Why would Joomla insist on doing that is beyond me. I;m afraid that the only 3PD contributions you can hope for is stupid small HTML stuff and trivial features. This is a damn shame but I won't loose my sleep over it. I can still offer these features I have been working on as third party extensions which WORK even if they don't give a rat's smelly ass about appeasing some tool written for a completely different use case.
No, I do not want the Joomla project to steal my code and my hard work
I'm sorry but this was not my intention I would like to move the code forward to be included to save your code and work from being wasted.
What I really want is a way to fix the JS code style validation errors.
Well as you know I'm not the JS guy but maybe this can help you:
https://github.com/joomla/joomla-cms/blob/4.0-dev/.eslintrc#L3
It seams we choose to use the airbnb-base rules. I don't have access to a PHPStorm instance but it might be worth trying the suggestions here: https://stackoverflow.com/questions/32547463/how-to-configure-eslint-to-work-with-phpstorm-to-autofix-eslint-errors
Here is a 5sec fix for you:
- Since you can not write modern (that ES6) javascript just remove all the ES6 (const/let etc) from your scripts and just rename them to
.es5.js
There you go, a bit of help from an elitist jerk
a silly change on https://github.com/joomla/joomla-cms/blob/4.0-dev/.hound.yml#L1
from
fail_on_violations: true
to
fail_on_violations: false
can do a temporary trick to let us to have this important feature .....
p.s
CS sucks
@dgrammatiko I ignored you on Twitter but you felt compelled to continue being a jerk here. OK, then, I will respond even though you should just get your comment deleted for a CoC violation (personal attack).
I have never made snide remarks about your PHP skills or possible lack thereof because you have said that you are a JS developer, not a PHP developer. Likewise, I've said many times that I am a PHP developer. I am NOT a JS developer and I don't consider my code to be any good, just working and readable by the average PHP developer (PHP developers being the contributor target audience of this CMS). The fact that you felt compelled to make a snide remark about my ability to effectively use a programming language I've said myself I am not fluent in is at the very least pathetic.
I am legitimately trying to write ES6 despite not being fluent in it. In fact, I did have working code! Not textbook ES6 but readable and working nevertheless. It transpiled correctly, it worked fine. I never complained that I can't write ES6 code. There are two problems I am complaining about.
The first problem is that there is no documented JS toolchain. The documentation page is just barely enough to compile and transpile code so that J4 can actually run. It does not explain where to put new JS files when contributing a new feature, it does not explain how compilation/transpilation works, it does not tell you about the .es5.js suffix you made your unnecessarily snide remark about. In fact, I asked THREE TIMES before I started contributing and was basically unceremoniously told to "figure it out". I am not a JS developer and I "figured it out" to the best of my abilities. The fact that NOBODY here knew about the .es5.js suffix before you came in does show that there is (was) a systemic problem with the JS developers who were let loose on the Joomla 4 codebase without documenting anything. Not only did you guys not document anything, you are making snide remarks against people who try to figure our WTF you did in a language they are not fluent with. Bravo! That's the spirit of FOSS and encouraging contributions. NOT.
The second problem is that you are convinced that the JS coding standard chosen is gospel and ideal because it is what a multibillion-dollar company wrote for its JS-based web applications and is now considered the de facto standard in the JS-based web applications industry. The very first observation that is glaringly obvious is that this industry has zero points of touch with the PHP-based, end-user-focused CMS industry this project is engaged in. The coding standard being used does not just enforce a coding style (which is what its PHP equivalent does). It is also enforcing code organization, use of language features and is unnecessarily opinionated on things beyond code styling. The end result is great if you are writing production code for a JS-based web application you deploy using your standard CI/CD toolchain but no so much for a mass distributed PHP based CMS meant for end users. In the end the JS it requires us to write is NOT something a PHP developer or end user trying to debug a JS issue can understand. This is a disservice to the Joomla community. Insisting that a standard for a completely unrelated industry is gospel is at the very least boneheaded.
Further to that, I'd like to express an additional complaint about the unnecessary blanket ban on jQuery code instituted by the project on your behest and insistence. Before you lash out with another of your abhorent derisions I need to clarify that I fully understand that using jQuery instead of document.getElementById and querySelector/querySelectorAll is bad for performance. I fully agree that we should educate developers to not use jQuery selectors when they are not necessary i.e. in most cases. There are, however, some cases where using the very well tested and well supported jQuery library makes sense. First, it has the best tested, most compatible JavaScript AJAX library you can find. Second, it has utility classes e.g. to add/remove CSS classes which are very well tested and doesn't make sense to replace. Instituting a blanket ban on jQuery and asking the project to completely remove jQuery from its distribution is doing a massive disservice to the community. Maybe you were not in the community back in 2007 to 2010 when Joomla! 1.5 was the Wild West of JavaScript and don't know or remember why the heck jQuery was added as a core library. I have been around since long before that time and I have lived through the consequences of the Wild West of JavaScript era. It's sad that the lack of institutional memory and a handful of vocal people with no connection to mass distributed software are dragging us back to these dark times. But I digress.
For this PR right here I had to waste my time trying to reinvent the wheel, namely AJAX. The Joomla.Request JS library that you wrote yourself a year to this day, Dimitri, does not build a POST parameter by itself among other missing features. That's why I had to come up with plg_system_webauthn_interpolate_parameters. This code is giving me an inscrutable ESLint error. I am basically screwed because you decided to write a subpar replacement to jQuery.ajax. That is to say, the final blow that made me give up is caused by missing features in your own subpar code. Had you implemented this basic feature I wouldn't be completely stuck.
Έοικα γούν τούτου γε σμικρώ τινι αυτώ τούτω σοφώτερος είναι, ότι α μη οίδα ουδέ οίομαι ειδέναι.
– Socrates
I rest my case.
The Joomla.Request JS library that you wrote yourself a year to this day, Dimitri,
You see that's not my contribution, this is something that exists since J3.6 or J3.5...
does not build a POST parameter by itself among other missing features
Actually, it does. There plenty of core scripts using that
The coding standard being used does not just enforce a coding style (which is what its PHP equivalent does). It is also enforcing code organization
Actually what you've experienced was bad, due to the fact that your code shouldn't be ES6 in the first place. I have no clue who you've asked and what they told you, all I know is that this particular code shouldn't be committed as ES6.
I have never made snide remarks
No, I just stated something obvious. Your code shouldn't be ES6 because it didn't magically became ES6 just by converting some var to const/let. The fact that I concluded that you cannot write ES6 is due to that simple observation. If you're offended I'm sorry. But you continue with the same aggressive pattern attacking me. Well, no comments on that although I think I know the reason...
Now back to the point:
- Just rename the files to .es5.js
- Rename all const/let to var
There you go, your PR is passing every sneaky bot.
You see that's not my contribution, this is something that exists since J3.6 or J3.5...
I know why I couldn't tell. When you moved files around you did it in a way that made Git treat it as a new file, created by you. Apparently you don't know git basics and destroyed the file history. Let's see how you're going to try and twist it as my problem.
Actually, it does. There plenty of core scripts using that
Actually no, there is not a single one. There are 32 occurrences of Joomla.request in build/media_source. The only POST request "building" is either converting an object to JSON OR interpolating values in a string. This is NOT the same thing. If you can't understand the difference maybe shut up?
Your code shouldn't be ES6 because it didn't magically became ES6 just by converting some var to const/let.
Only you could read what I wrote above and believe that this is what I think. Unlike you, I am not an ignorant moron. I understand the difference between ES6 and ES5, thank you very much.
There are exactly TWO reasons I created an ES6 file.
One: I was given fuck all guidance despite asking Harald and George desperately over email and Skype. I told them I am not a JS developer and they threw me under a bus (and remained silent in this issue).
Two: in fact there is a bit that is ES6 and came right out from the 3PD library I am using. As I said, I don't speak ES6 and I tried to extend that code based on my limited understanding of a language I don't speak. Thank you very much for continuing to make fun of me.
Here's what.
- I told you Harald and George that I need help with JS and you didn't care. I tried to contribute nonetheless and see where we are now. I feel like I was thrown under a bus.
- All this JS stuff is undocumented and inscrutable for someone who's not a JS developer. Yet you consider the developer trying to contribute liable for Joomla's undocumented mess.
- You have fucked up Git history, attributing code to the wrong people. But somehow it's the fault of the person using git-blame that you have fucked up Git's history?
- I never called you out by name, Dimitri. You popped up on Twitter uninvited and you popped up over here also uninvited. If your goal was to make me NOT contribute an very important security feature to Joomla you have achieved your goal.
I forbid the Joomla project from using my code, in whole or in part, in any upcoming version of Joomla. I am deleting my branch and all the work I've done. I am sorry I wasted my time with you idiots. I should have known better.
Thanks for trying to contribute Nik, I didn't read the back and force between you an Dimitri. If you both have a problem with each other, githhub is not the place to fight this out. The feature you are proposing is interesting and for sure something Joomla! need. What we don't need are people calling other idiots. Please show others the respect you want to get too.
@nikosdion first of all thank you for your work and as I told you I will support you with this feature as much as I can.
The main problem you as I see is that you expect that someone help you in a really short time frame.
You spent a week or more for this really awesome feature and want to waste it because you want to wait several hours until someone can help you? That makes no sense to me.
So I hope you can rethink your decision and reopen this PR so we can make Joomla! better together.
PS: I'm not comment your rant and calling us all idiots because there is nothing to discuss it's simple not acceptable. So please change your language.
Just for future visitors: This is the first result in Google for "joomla codestyle": https://developer.joomla.org/coding-standards/introduction.html
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25797.
Just for future visitors: This is the first result in Google for "joomla codestyle": https://developer.joomla.org/coding-standards/introduction.html
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25797.
@HLeithner Really? Short timeframe?!!! I have been trying to contribute this feature since April 2019. After numerous reminder contacts with George he told me he notified you. It took another two reminders over the next month and a half for you to email me on July 5th. That's also when you asked me to change my jQuery-based JavaScript. I warned you this is a bad idea and actually wrote "I will do it but not because I think it will help with anything, I only do it because I am explicitly asked to and despite me strongly disagreeing with the reasoning.". I also asked you what do you expect me to do with JavaScript, write my own, use Joomla's, how to proceed. You kept addressing all of my other points except this one.
Silence for two weeks. I am just sitting there, wondering WTF I am being ghosted by the Joomla project. Then I receive a reply on July 21st, without much of an apology or explanation as to why I was ghosted for two weeks. But I digress.
On July 21st in my reply to you I wrote in bold, red letters at the top of my email "I still need an answer to my question about JavaScript.". On the same day you replied and I quote including all your misspellings and grammar mistakes: "1) We have to avoid jQuery and have to use es6 vanilla JS earlies or later jQuery will die and Joomla should have the next vendor login especially in Frontend. So please don't use jQuery.". Upon request for clarification on WTF you really want me to do on the same day (that is, another two emails back and forth) all you did is point me to https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/core.es6.js#L845 as your only reply. That was your last communication to me. I was left with questions nobody was trying to answer to fend for myself and figure Joomla's shit out.
As you may have noticed, I was EXPLICITLY asked to write ES6 despite obviously not being a JS developer, I was never told there is a coding style to follow or that a bot would yell at me sending in a PR and you didn't even give me any guidance on how I am supposed to write and transpile EcmaScript 6. I did try to locate documentation myself but as you can read in the page that Hannes helpfully linked there is no mention at all about a JS code style even today, two weeks after I closed this PR.
If you are wondering why I got upset when filing this PR: at this point I had been chasing you people for MONTHS trying to contribute my code. I had spent a lot of time trying to extract a bloody answer from you about my reasonable questions about the things you asked me to do. I got none. I wasted even more time trying to figure things out myself. Finally I had something that worked. Then I submit the PR and a bot starts yelling at me about a coding standard that is documented NOWHERE. The instructions given in the errors are conflicting, confusing and unintelligible to someone who's not an experienced JS developer (a requirement that was never mentioned in the months I've been chasing you people around). I have that sinking feeling that I have been thrown under the bus by a maintainer who doesn't give half a rat's ass about me. And then there's this guy who starts mocking me for trying to figure things out because the maintainer I was told to contact set me up for failure. So, yeah, at this point I am mighty pissed off. All of this was avoidable and you had PLENTY OF TIME to proactively help me.
At this point I expect a great leader would apologise for the situation he caused by failing to a. proactively provide the contributor with adequate information and b. stop the attacks against the contributor. Instead, I get a condescending message "you're a cry baby, you're crazy for not giving us your code anyway". Are you for real?! Not only your help is too little, too late but your adding insult to injury is absolutely certain to not only dissuade me from contributing this feature to J4 but also drive me away from any kind of contribution to this project.
In any case, I do apologise for calling you idiots. I meant to say something entirely different. You are completely unfit for leadership positions because you don't care about proactively helping and supporting contributors even when they explicitly ask you. You have zero empathy and treat people like they don't matter, alienating them from a project that desperately needs contributors. I regret having wasted my time trying to help Joomla despite it being very clear from the start that you are uninterested in your role in the project and won't do anything for contributors beyond hollow, perfunctory and untimely answers. I regret wasting my time trying to discover myself all the missing bits none of you people bothered to document while developing Joomla! 4, despite all of us having that recurring conversation over the last decade about contributors and users being unable to read your damn mind so document the darned thing, dammit!
As for my time developing the WebAuthn integration for Joomla, i.e. the code I wrote back in March and updated in July, it most definitely does not go to waste. As I had already told you since April I have already written a plugin for this feature and I updated it with some of the backend changes I made while trying to make my contribution. You can find it here https://github.com/akeeba/passwordless Next week I'm back from vacation and will release it properly on JED. It works with both J3 and J4 (as of alpha 10). It's also GPLv3 so no funny ideas about stealing my code, it'd be illegal (that's another discussion we've been having for a decade...).
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25797.
@HLeithner Really? Short timeframe?!!! I have been trying to contribute this feature since April 2019. After numerous reminder contacts with George he told me he notified you. It took another two reminders over the next month and a half for you to email me on July 5th. That's also when you asked me to change my jQuery-based JavaScript. I warned you this is a bad idea and actually wrote "I will do it but not because I think it will help with anything, I only do it because I am explicitly asked to and despite me strongly disagreeing with the reasoning.". I also asked you what do you expect me to do with JavaScript, write my own, use Joomla's, how to proceed. You kept addressing all of my other points except this one.
Silence for two weeks. I am just sitting there, wondering WTF I am being ghosted by the Joomla project. Then I receive a reply on July 21st, without much of an apology or explanation as to why I was ghosted for two weeks. But I digress.
On July 21st in my reply to you I wrote in bold, red letters at the top of my email "I still need an answer to my question about JavaScript.". On the same day you replied and I quote including all your misspellings and grammar mistakes: "1) We have to avoid jQuery and have to use es6 vanilla JS earlies or later jQuery will die and Joomla should have the next vendor login especially in Frontend. So please don't use jQuery.". Upon request for clarification on WTF you really want me to do on the same day (that is, another two emails back and forth) all you did is point me to https://github.com/joomla/joomla-cms/blob/4.0-dev/build/media_source/system/js/core.es6.js#L845 as your only reply. That was your last communication to me. I was left with questions nobody was trying to answer to fend for myself and figure Joomla's shit out.
As you may have noticed, I was EXPLICITLY asked to write ES6 despite obviously not being a JS developer, I was never told there is a coding style to follow or that a bot would yell at me sending in a PR and you didn't even give me any guidance on how I am supposed to write and transpile EcmaScript 6. I did try to locate documentation myself but as you can read in the page that Hannes helpfully linked there is no mention at all about a JS code style even today, two weeks after I closed this PR.
If you are wondering why I got upset when filing this PR: at this point I had been chasing you people for MONTHS trying to contribute my code. I had spent a lot of time trying to extract a bloody answer from you about my reasonable questions about the things you asked me to do. I got none. I wasted even more time trying to figure things out myself. Finally I had something that worked. Then I submit the PR and a bot starts yelling at me about a coding standard that is documented NOWHERE. The instructions given in the errors are conflicting, confusing and unintelligible to someone who's not an experienced JS developer (a requirement that was never mentioned in the months I've been chasing you people around). I have that sinking feeling that I have been thrown under the bus by a maintainer who doesn't give half a rat's ass about me. And then there's this guy who starts mocking me for trying to figure things out because the maintainer I was told to contact set me up for failure. So, yeah, at this point I am mighty pissed off. All of this was avoidable and you had PLENTY OF TIME to proactively help me.
At this point I expect a great leader would apologise for the situation he caused by failing to a. proactively provide the contributor with adequate information and b. stop the attacks against the contributor. Instead, I get a condescending message "you're a cry baby, you're crazy for not giving us your code anyway". Are you for real?! Not only your help is too little, too late but your adding insult to injury is absolutely certain to not only dissuade me from contributing this feature to J4 but also drive me away from any kind of contribution to this project.
In any case, I do apologise for calling you idiots. I meant to say something entirely different. You are completely unfit for leadership positions because you don't care about proactively helping and supporting contributors even when they explicitly ask you. You have zero empathy and treat people like they don't matter, alienating them from a project that desperately needs contributors. I regret having wasted my time trying to help Joomla despite it being very clear from the start that you are uninterested in your role in the project and won't do anything for contributors beyond hollow, perfunctory and untimely answers. I regret wasting my time trying to discover myself all the missing bits none of you people bothered to document while developing Joomla! 4, despite all of us having that recurring conversation over the last decade about contributors and users being unable to read your damn mind so document the darned thing, dammit!
As for my time developing the WebAuthn integration for Joomla, i.e. the code I wrote back in March and updated in July, it most definitely does not go to waste. As I had already told you since April I have already written a plugin for this feature and I updated it with some of the backend changes I made while trying to make my contribution. You can find it here https://github.com/akeeba/passwordless Next week I'm back from vacation and will release it properly on JED. It works with both J3 and J4 (as of alpha 10). It's also GPLv3 so no funny ideas about stealing my code, it'd be illegal (that's another discussion we've been having for a decade...).
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/25797.
Hey, maintainers. It would be great if there was a. any indication that there is a JS style guide (or where to find one) and b. you included it in a standard EditorConfig file of the project. Having to go back and forth with an automated bot is a waste of time.