[#37912] - Multi-Factor Authentication (replaces Two Factor Authentication)
- Fixed in Code Base
- 4 Jun 2022
- Medium
- Build: 4.2-dev
- # 37912
- Diff
- nikosdion:feature/tfa
User tests: Successful: Unsuccessful:
Improved Two Factor Authentication
Replaces #37811
ATTENTION TESTERS
This PR replaces plugins and has changes in the JavaScript. If you are not using a prebuilt package you need to do the following:
- Run
composer install - Run
npm ci - Delete the file
administrator/cache/autoload_psr4.php
Executive Summary
This PR implements Multi-Factor Authentication (MFA) using a “Captive Login” approach.
Unlike the temporary Two Factor Authentication solution that was supposed to last for a maximum of one year and we've been using until today (nine years later...), it does NOT require you to enter your Security Code with your login information (e.g. username and password). In fact, there is no longer a Security Code field at all in the login module or page. Instead, you login using whichever login method you want to use. Then you enter the “captive login” mode in Joomla where you can only interact with a subset of com_users: you can proceed with MFA validation, choose a different MFA method or log out. Non-HTML views are forbidden.
Tagging @SniperSister @richard67 who were involved in the original discussion in the context of improving Joomla's security, @zero-24 @bembelimen @roland-d @HLeithner as the current and future release leads that need to be in the loop, @Kostelano and @heelc29 who participated in the previous PR.
Extra features implemented and considerations made
I implemented a few extra features to the old TFA since I already had the code for them and it'd be a waste to remove it only for someone else to try and replicate them in the future. I also tried to be very considerate of the security of the solution, keeping it in a fine balance with practicality. Without further ado, here's what I did.
Multiple MFA methods per user. There is no good reason why a user shouldn't have multiple MFA methods. In fact, it is a better approach e.g. having two WebAuthn keys (main and backup) and a classic six-digit code for use in an older smartphone which doesn't support WebAuthn dongles. This makes MFA more usable and more resilient to accidents that lock people out of their site.
Default method. If you have multiple authentication methods you don't want to stop and think which method you will be using to authenticate today, especially since you're likely to use the same method 99% of the time. Therefore you can pick which method will be your default. You can NOT use emergency codes as the default method to reduce the probability of silly mistakes.
Methods batching. Let's say you set up three WebAuthn authenticators. When you log in you want to see a single page asking you for a WebAuthn login, not having to click to select which WebAuthn authenticator you will be using (reduces the PICNIC errors — Problem In Chair, Not In Computer). I call that method batching because you can batch process all instances of a MFA method using a single input. WebAuthn and YubiKey let you set up multiple instances of that method so, indeed, they support method batching. Regular Authentication Code and Authentication Code by Email only allow a single instance so they don't. As simple as that.
Automatic migration of legacy data. To support multiple MFA methods per user we moved the MFA data from the two #__users columns (otpKey and otep) to its own table (#__user_tfa). Any already set up legacy TFA method is automatically migrated upon first login. This means that MFA will migrate cleanly even on sites with hundreds of thousands of users, something which would NOT be the case had we performed the migration during update (we'd timeout as we have to load each record individually, decrypt it, convert it, re-encrypt it and save it). Important: Until a user goes through a login you will NOT see their TFA/MFA status or configuration settings in com_users in the backend.
Data is encrypted. As alluded above, the MFA configuration data is still encrypted using AES-256 using a key derived from the site's secret. Therefore a simple SQLi vuln in any extension won't divulge the secrets for MFA.
New MFA methods. You can now use Authentication Code by Email and WebAuth on top of the existing Authentication Code and YubiKey methods. The former sends you a 6-digit code to your email and can also be set up to be forcibly enabled for anyone (to provide a viable backup if your users are not very tech savvy). The latter supports Windows Hello and Android, bringing in the improvements from my other PR (#37675).
Forced MFA and Forbidden MFA groups. You can optionally set up certain user groups to have MFA forcibly enabled and other groups to have MFA forcibly denied. The former will have to set up MFA and use it to continue using the site. The latter will never be asked to go through MFA, even if they had previously enabled it, nor will they see the MFA configuration section in com_users.
Onboarding to drive adoption. You can optionally have users (who do not belong in the forbidden MFA groups!) be automatically shown an onboarding page if they log in and they have not yet enabled MFA. They can set up MFA, go to a different page or forever dismiss the onboarding page. You can also customise the onboarding URL, e.g. if you want to display your own article instead of showing the default MFA setup page. According to my experience this increases MFA adoption by a factor of ten. Note that onboarding is DISABLED by default; we don't want people coming at us with torches and pitchforks for ruining their site's login experience.
Super Users cannot edit other Super Users. As a Super User you cannot touch another Super User's MFA settings at all. Consequently, if you mess up your MFA as a Super User you need to do some database editing. There's only so much we can do.
Administrators can only remove TFA options for other users. As a privileged user you can only remove MFA options from other (non-Super Users) user accounts, or disable their MFA completely. You cannot edit their TFA configuration or enrol new MFA methods.
Single click disable. The MFA configuration interface includes a Turn Off button which disables MFA completely for your user account. This is useful if you lost access to all MFA methods, you have used an emergency code and you just want to turn the darned thing off until you sort out your other problems.
Post-installation message. The old PIM for MFA has been removed and a new one has taken its place.
Module positions customisation in the captive page. You can choose which module positions to display in the captive MFA page. This lets you display, for example, your site's header and footer to give users a better visual experience.
No MFA on silent logins. By default, MFA is disabled on silent logins. You can toggle that as well as customise which login methods are to be considered a "silent" log in. By default these are the Cookie Authentication (remember me) and Passwordless (WebAuthn). The latter needs some explaining. WebAuthn is phishing-resistant and insanely secure — we only ever store a public key in the database, even if it's stolen it cannot be used to log you in (a stolen password hash can be brute forced MUCH more easily, by several orders of magnitude). This means that WebAuthn is strong enough to NOT require Multi-factor Authentication. That's the whole point of WebAuthn; replace usernames and passwords and the need for multifactor authentication with One Authentication Method To Rule Them All And In Security Bind Them.
Implementation notes
This PR is based on my past work on Akeeba LoginGuard, in active development since 2016. Back in late 2013 when I contributed the Two Factor Authentication feature we had agreed that entering the security code with the username and password was a bad idea but we only intended it as a temporary solution until Joomla 4.0 would be released in late-2014 to early-2015. Obviously the release plan changed and we got stuck with the old TFA method for nine years. Meanwhile, LoginGuard proved that my original idea of a captive login is feasible even without core changes and that code pattern found its way into later Joomla 3 and 4 versions e.g. com_privacy's plugin to provide consent and requiring a password reset.
This being a core PR instead of an extension I no longer have to use a weird system plugin to make the captive login work. I also didn't want to repeat the past mistakes of sprinkling magic code all over the darned place to integrate MFA to Joomla. So I used a Trait instead. Only the SiteApplication and AdministratorApplication use it. This is deliberate.
The CLI application does not have any authentication to speak of, nor it needs to. If you are in a position to either access a shell or define CRON jobs you have more control on the hosting environment than a Super User.
The Api application on the other hand is non-interactive. That's why it has a token authentication instead of relying on a username and password (see #27021 and the handy comic panel that drives the point home in #26925).
So, if you end up writing an interactive custom application you can use the Trait. If not, it's cool, DON'T integrate MFA — you actually MUST NOT.
Missing odds and ends
I have not integrated this with Joomla's Action Log. This is deliberate as there's currently an open PR (#37788) touching it and I don't want to create a Merge Conflict Hell.
Integration with Action Log should be a separate PR after this one is merged. Let's learn to walk before we learn to run.
Votes
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | Administration com_admin SQL Postgresql com_joomlaupdate com_users |
The OTP alert is not full width, although all other alerts are full width. Look at the adjacent tabs in the profile settings or, for example, at the entrance, when we are redirected to the MFA information page.
Also, I noticed that you increased the header size with fs-3. It catches the eye. My humble opinion - without this class it was better.
Update: resolved
Captive login as manager
This is caused because the manager does not have access to the administrator interface of com_users. It doesnt make a huge ammount of sense to change the permission so I think there needs to be a different way.
Note that as shown in the screenshot the login is not captive when you get an error page
Correction
it was onboard new users not captive login that caused this
| Labels |
Added:
?
|
||
@Kostelano I addressed your feedback.
@brianteeman Sigh... This is why I wanted to have this as a different component but the production leadership insisted on having it a com_users feature. Let me think how to do this in a way that doesn't introduce any security issues.
@nikosdion Perhaps we should reconsider and make this a separate component. I really do not think it is a good idea to give users access to com_users to setup their MFA. I have posted it in the production team.
@roland-d We are in it too deep to change the overall structure. Don't worry, mate, I know how to do it. I have done the same in Akeeba Ticket System where the same component can be used by end users with no administrative privileges and support ticket managers with administrative privileges. Half of what we need is already in the Controllers I wrote. The other half is adding exceptions in the Dispatcher for the MFA-specific views. Since all tasks of all MFA views do their own access control we're good. Defensive coding by default pays off when issues like that arise.
In other words don't worry, my healthy dose of security paranoia is about to pay off dividends.
@brianteeman @roland-d There you go. Managers and any backend user without core.manage on com_users can now use the MFA sub-feature of com_users to manage their own MFA and nothing else.
If you're wondering how having access to manage.delete, for example, doesn't allow managers to delete the MFA of other users: the ManageController::delete calls assertCanEdit which calls Mfa::canEditUser. The latter will only return true if you are editing your own MFA or if you are a Super User and who you are editing is NOT a Super User.
Update: resolved
Sorry that doesnt work.
It might be better to use the classic prompt below the field so that it doesn't differ from other Joomla options.
There is a disproportion in badges for admin/front templates. Consider reducing the badge in the front.
@brianteeman It worked, I just forgot to remove the Back button. Try now, it's fixed.
Update: resolved
@brianteeman It worked, I just forgot to remove the Back button. Try now, it's fixed.
almost but not quite
@brianteeman Back button terminated with extreme prejudice.
@Kostelano The only thing that cannot be fixed is the font size in the frontend. Unfortunately, these minimum font sizes are hardcoded in Cassiopeia's SCSS. Having tried to fix that and being told to adjust it in my browser (a. it's outright impossible in Safari and b. with the rest of the web using 0.9rem as the base font size it means the rest of the web becomes teensy tiny) all I can tell you is that I can't fix it. If you want you can submit a separate PR to Joomla to address the font sizes but if I were you I'd think twice before deciding to die on that particular hill.
@brianteeman Back button terminated with extreme prejudice.
that seems to have resolved that in the admin
Update: resolved
Next problem
In the list view of users the column showing MFA is wrong. Below you can see that the super user does not have MFA enabled and the manager does have MFA enabled but the list view says otherwise
Update: resolved
when you read this as one sentence then it is correct to write "Backup Codes let you ...
When you read this as two sentences then it should be "Backup Codes. Lets you ...
As this is a title followed by a sentence I would change it to the second
Post Installation messages
Something is going wrong as I can see there is aa query to remove the tfa message and to add a mfa message - but thats not happening
@brianteeman disable all MFA plugins
@brianteeman disable all MFA plugins
its a clean install
If you enable the Onboard new users parameter in the user settings, then enter the site in the frontend, we get to the page with information about the MFA. Here we will add a method, after confirmation we will get to the page where the heading Your Multi-factor Authentication method will be. It only appears here (if we are talking about the front). It seems to me that it is superfluous and I propose to remove it. When editing a profile, this header is not there; in the admin panel in the profile, it is also not there.
its a clean install
Yes, that's how it works. And it worked with TFA. If at least 1 plugin was enabled, no message was displayed. Since we have 4 plugins enabled in a clean install, no message is displayed.
It probably still needed to be displayed to inform users, but in general the behavior has not changed since the introduction of TFA.
its a clean install
Yes, that's how it works. And it worked with TFA. If at least 1 plugin was enabled, no message was displayed. Since we have 4 plugins enabled in a clean install, no message is displayed.
It probably still needed to be displayed to inform users, but in general the behavior has not changed since the introduction of TFA.
That's a bug then as its not a "post-installation" message if there is a condition (no mfa plugins enabled) that cannot be met
As they are enabled already on a clean install this can only ever be displayed on an update.
I agree that displaying the action can be conditional but not the message itself.
Enforce MFA (admin)
- Set Enforce Multi-factor Authentication to manager
- Set Onboard new users to yes
- Create a new manager and try to login to the admin
Expected behaviour
Onboard page without any possibility to proceed without setting up MFA
Actual Behaviour
Onboard page with modules and possibility to proceed and do anything a manager can do
Input validation and filters
I thought, and I can be wrong, that all inputs in forms are supposed to have filters and/or validation on th input
I am not at the office but I can tell Brian about all of his wrong assumptions.
Post-installation. Read the previous PR’s discussion and this PR’s description. Think hard about migrating vs new installation and you will see why what you say is daft. I am not going in circles about something already discussed and resolved.
Onboarding. You conflate onboarding with forced use of MFA. THESE ARE TWO DIFFERENT FEATURES. Feedback ignored as nonsensical non-issue.
MFA status. Works for me but I’ll check again on Monday.
Please use your brain, Brian. THINK before you comment.
Respectfully please check more carefully what I have said
Not going to waste any more time testing this
Update: resolved
The label is for com-users-method-edit-code
The input is com-users-method-code
They must be the same
Update: Resolved
Backup Codes
When you add MFA to your account AND you have all the plugins enabled then its a long list.
After adding your first method an additional option is displayed for backup codes
Quite rightly you're highlighting this etc as its so essential for a user to do
The problem is that it is too easy not to see that backup codes have been added to the page. Possible solution woulf be to add backup codes to the top of the list and not the end of the lis.
Demo cassiopeia
update: resolved elsewhere
Onboard new users 403 on logout
403 when logging out from the onboarding page without setting up any MFA
Update: resolved elsehwere
Display User Profile
If you have a menu item to display the user profile it is displayed with the basic details and the status of any webauthn . Should it not also show if any MFA are configured?
403 when logging out from the onboarding page without setting up any MFA
That's the unfortunate way of how the Joomla logout button works. When you log out you are redirected to the same URL you were before unless the login module is set up with a logout redirection URL. If there was no redirection URL and you were viewing any access-restricted page you get a 403 error.
The same thing will happen if you are editing your user profile or viewing an access-restricted article and click on the Logout button — and that's before this PR is applied; it even happens on Joomla 3.
There are two possible ways to handle this issue:
- The One True Joomla Way: consider it normal, do nothing and move on. That's what I did as that's how the rest of Joomla works.
- Instead of returning a 403 when there is an access error redirect the user to the home page of the site. However, this would make the MFA feature work in a way that's different than the rest of Joomla.
Therefore I am inclined to leave it as-is. The One True Joomla Way solution is for the site owner to set up a logout redirect URL for the login module.
Should it not also show if any MFA are configured?
It never did with TFA. I am keeping it the same.
I would say that it shouldn't even show the WebAuthn information. There is no point showing login-related detailed information in the profile display. These only make sense when editing the profile. If at some point user profiles become public — there is a much-needed use case in real world sites which now have to install “social web” solutions even if all they need is a public profile display — the login information should most definitely not be part of the public profile.
As for WebAuthn, if I recall correctly, the context sent when viewing and when editing the profile is the same therefore the WebAuthn system plugin cannot know when NOT to add its fields. That's why all it can do is add an HTMLHelper hook to render its field differently than when editing the profile. That hook is called too late in the process to let WebAuthn remove its fields from the user profile form.
If you have found a reliable way for WebAuthn not to show itself when viewing a profile please do a PR and tag me.
I have been testing it a little as well, it is looking good
A few things I noticed:
- When you have no mail template (for whatever reason) there is no email sent but when you are setting up the
Code by emailit says that you have received an email. Should we check if the email template exists? - When you remove the last active MFA method by clicking the delete button on the method, you still have backup codes. Should these be removed? They are removed if you click the
Turn offon the top of the page. - I find the
Add a new ..buttons really big. Setting the button classes tobtn btn-secondary btn-smlooks better I think.
When you have no mail template (for whatever reason) there is no email sent but when you are setting up the Code by email it says that you have received an email. Should we check if the email template exists?
How would you end up in such a situation? I mean, sure, I can catch that problem but I can't think of a way you end up like that without deliberately sabotaging your site.
When you remove the last active MFA method by clicking the delete button on the method, you still have backup codes. Should these be removed? They are removed if you click the Turn off on the top of the page.
I know. I am trying to see if there is a reliable way to do it.
I find the Add a new .. buttons really big. Setting the button classes to btn btn-secondary btn-sm looks better I think.
Okay. I'll change them.
How would you end up in such a situation?
In my case the SQL query was not executed, simply because I forgot. The way users maintain their website anything is possible. I know it may be far-fetched, just wanted to put it out there.
update: resolved
Re the 403
That might have been the situation in the past - I dont remember - but its not the situation now. With sample data installed and you use the module log out button on a restricted page you are redirected to the login page with an error message. Not great but better than the 403. Try it and see
@roland-d Regarding the code by email, it makes more sense to send the email using the traditional way if the mail template is missing than failing. It prevents the user from getting locked out or having to make a DB query every time we evaluate MFA to see if we should use the Code by Email feature. Everything else I did.
@brianteeman OK, I am not redirecting to the login page.
@nikosdion Fair point we don't want to check the existence of a mail template. It is not an issue for just this PR but the mail templates in general, so I would just leave it as it is.
I still dont like the way the button is split onto two rows like this
Please reconsider my pr nikosdion#8
Email by code
The input field is of type number which means it displays a spinner and a screen reader will do things like announcing the min and max values and the step (even if you dont explicitly set them)
I would probably change that to
<input type="text" pattern="{0,9}" maxlength="6" inputmode="numeric">
note the inputmode is for mobile devices
Authenticator app - debug?
Please check your authenticator app setup, and make sure that the time and time zone on your device is set correctly.
Tried multiple authenticator apps on my phone and each time the verifcation code is rejected. The time and time zone on my phone are set correctly (its done automatically)
Any suggestions how to debug this further
It is not an issue for just this PR but the mail templates in general, so I would just leave it as it is.
I agree. I found the same issue with my software. My solution was to have an Email Templates page in my extensions which can be used to add missing templates or reset email templates to default. Maybe Joomla could do the same, albeit it would require having the email templates in a third place apart from the two SQL files per DB server type.
I still dont like the way the button is split onto two rows like this
I have a better solution than your PR already written — and an even better one I thought about last night. I'll do that today.
Tried multiple authenticator apps on my phone and each time the verifcation code is rejected. The time and time zone on my phone are set correctly (its done automatically)
Check the timezone in your php.ini and the server timezone in your global configuration. These would be used to convert the date and time reported by the system clock to the UNIX timestamp used by Joomla's TOTP class. Remember that I have not changed the TOTP implementation in this PR; I am using the one already in Joomla since 3.2.
The input field is of type number which means it displays a spinner and a screen reader will do things like announcing the min and max values and the step (even if you dont explicitly set them)
I cannot get a screen reader to announce a min/max value if one is not set. It does announce it as a spinner. Which screen reader are you using? I am trying to understand the nature of the problem so whatever I do to solve it is not a blind change (no pun intended).
This is a summary of how the different screen readers respond to a input type=number field https://a11ysupport.io/tests/tech__html__input__input-number
As you can see the behaviour I described is from windows narrator, which as reported by the webaim survey was used by 36.8% of respondents and is increasing year on year
I still dont like the way the button is split onto two rows like this
I have a better solution than your PR already written — and an even better one I thought about last night. I'll do that today.
I dont care how it is fixed just that it is. My pr was the minimal change to achieve the aim. It was not how I would have created it from scratch.
Tried multiple authenticator apps on my phone and each time the verifcation code is rejected. The time and time zone on my phone are set correctly (its done automatically)
Check the timezone in your php.ini and the server timezone in your global configuration. These would be used to convert the date and time reported by the system clock to the UNIX timestamp used by Joomla's TOTP class. Remember that I have not changed the TOTP implementation in this PR; I am using the one already in Joomla since 3.2.
I suspect thats the case as well BUT the error message only refers to my authenticator device time and nothing about server time. Hence the confusion/query
the behaviour I described is from windows narrator
Thank you! This helps a lot. That's what I was asking for in the previous PR :)
I suspect thats the case as well BUT the error message only refers to my authenticator device time and nothing about server time. Hence the confusion/query
As you've said before, error messages cannot be full documentation. In most practical uses cases the php.ini is maintained by the host and has the correct timezone. The only practical problems we've seen in the last 12 years we've implemented TOTP — counting all the way to when Admin Tools Pro was the only way to add TFA to Joomla — was someone's device having the wrong timezone. The number of people who manually set the time every six months on their mobile phone is staggering. I didn't believe it either.
It was not how I would have created it from scratch.
I know. You would have each authenticator render its own HTML page which is how Joomla tends to do things — same reason the old TFA was implemented like that — but is unmaintainable if you have more than one authenticator, or you're using a template other than Joomla's default, or you're using a non-core authenticator.
The solution I am going to implement will remove (most of) the custom HTML from WebAuthn and can serve as a template for custom third party authenticators.
This means that we'll only need to change things in one place and one place only to change the layout of any authenticator and template, even non-core ones, to maintain a consistent experience. Doing that will also let me offer you the option to display the Validate, Log Out and Select Another Method buttons in the backend in the toolbar instead of the main page area which is another feedback point I have not forgotten about, thank you very much.
Your comment also demonstrates what is wrong with Joomla contributions the past few years. There are people who are site integrators / instructors and people who are code architects. Each cohort is far removed from the other. The people who would straddle both cohorts have stopped contributing to Joomla.
What I am trying to do here is NOT tell you that I know everything and can get everything right the first time; that's impossible. I am trying to listen to everyone's feedback and come up with the best compromise which will provide a consistent, easily customisable interface for everyone without tonnes of busywork and at the same time have an architecture which isn't antithetical to progress and future improvements. These are all the areas the legacy TFA failed miserably.
It naturally takes a lot of iterations to get there. To this end I prefer constructive feedback than dismissive remarks, querulousness and self-pity, if you don't mind.
yes it was the server time.
What I am trying to do here is NOT tell you that I know everything
That is absolutely not how it comes across at all.
That is absolutely not how it comes across at all.
A good senior developer knows when to say “no” and explains why. That's what I do. I am sorry that you don't try to understand the “why” after having it explained to you. Maybe if you talked to users and actually listened to them I wouldn't have to explain. Instead, you declare that you know best and when real world users complain you tell them they are stupid. It's funny how you're now doing what you were making fun of ten years ago.
Think about this. You are a mobile user. The only buttons you have are in the toolbar. You log into the site and you see the MFA code box. You enter the code and... what? It's completely non-obvious that you need to expand the TOOLBAR to click on the Send button. Of course I will object to that kind of interface and will look for a better solution.
You could have provided constructive feedback towards that end. All I got in return is “you're not trying to help” and ”It was not how I would have created it from scratch”. This is toxic, obviously false and completely stupid.
If I was here for a code dump I wouldn't be engaging with anyone. I'd have renamed com_loginguard to com_mfa and be done with it in an afternoon.
If you think you could have done it better from scratch: you had 9 ½ years. Where's your code?
Anyway, I don't care about your negativity and toxicity. I have figured out a way to do this despite you (and not thanks to you) so I will be doing it.
You need to address your behaviour. I don't give a rat's behind if you do that to me. The problem is you're doing that to everybody. That's not conducive to collaboration. If you're not part of the solution you're part of the problem.
I have two MFA methods set up: Totp (default) and Email.
After deleting Totp, there is no longer a default method.
If I try to login, the backup codes are "default".
@heelc29 I am trying to reproduce this but I can't. I am not sure if you are using the latest code, though. I made a change yesterday, if you remove the last MFA method the backup codes are also removed. Is it possible that you have an older version of the code which doesn't remove the backup codes in this case?
Is it possible that you have an older version of the code which doesn't remove the backup codes in this case?
I'm pretty sure I use c589be1.
For information: I have two MFA methods set up and delete only one of them (the default one). So the second one (in my case the email option) still exists.
I can try it later again.
Update: resolved
great to see the toolbar now
small error on the back button here
I think its missing the index.php
Update: resolved
on the page listing all the methods there are edit/delete buttons.
These link have identical text, although they point to different pages. Multiple links with the same text may cause confusion for people who use screen readers.
Suggestion would be to change them so that they say "Edit {method}" instead of just "edit"
Update: resolved
The toolbar back button is not rtl aware. All other instances of the back button in joomla change the direction of the arrow when in RTL. the code for this is something like
When you try to modify an existing yubikey you correctly do not see the Yubikey Identification input and see an appropriate message
You have already set up your Yubikey (the one generating codes starting with ccccccdhuujj). You can only change its title from this page.
With the authenticator app method you still see the three setup methods and just the verificatioon input is missing and no information about it being setup already. I understand that it may be correct to still display the three setup methods as you might have a new app etc but should there be some explanatory text as well
I understand that it may be correct to still display the three setup methods as you might have a new app etc but should there be some explanatory text as well
I think it's self-explanatory? I didn't want to add another message to a long page. What would that message read anyway?
Icons in the admin panel and on the front - in one place there is a white background, in the other there is not.
Maybe we can remove mx-1...? Both in the front and in the admin panel.
When you create a method - fields "in the standard Joomla format". When you log in - in another. I don't know if this is by design or a bug, but I would argue that the standard one-line approach is better and more familiar.
When we login and switch to one time password login, we don't have a description. Perhaps the line is present in the localization file, but is missing. Please check.
I think it's self-explanatory?
obviously not as I was wondering why the field was not present
Icons in the admin panel and on the front - in one place there is a white background, in the other there is not.
It's the same bg-light in both cases. We need bg-light so the image does not disappear over bg-secondary and/or on templates where the default card background colour is not fully or almost fully white.
Cassiopeia and Atum are written by different people who chose to use different colours for bg-light and literally every other base colour in the template.
After this PR is merged you are welcome to file your own PR changing the bg-light colour in Cassiopeia. If you want to die on this hill I won't stop you — but I won't die on that hill myself. Implementing MFA in Joomla is orders of magnitude more important than adjusting the light background colour value in Joomla's default frontend template by ~3%.
Maybe we can remove mx-1...? Both in the front and in the admin panel.
No. It was like that after I implemented your suggestion last time but especially in the frontend it becomes confusing as there is no visual hierarchy to indicate that each MFA method belongs under the MFA header. They look like unrelated bits of information without the padding. Keep in mind that at least 90% of Joomla's target audience has no idea what MFA is and in need of a certain degree of handholding and gentle visual cues.
I will keep this little margin unless there is a UX study backed by user testing proving it wrong.
When you create a method - fields "in the standard Joomla format". When you log in - in another. I don't know if this is by design or a bug, but I would argue that the standard one-line approach is better and more familiar.
This is by design. The decision was made after thinking about it and trying both approaches.
Horizontal forms (what you call "one line") is used to present multi-field forms in a more compact manner. This is not the case here; we only have one field.
Using a horizontal form layout looks out of place on large and extra large display sizes (display sizes per Bootstrap nomenclature): there's an ocean of whitespace.
At the same time, it looks unnecessarily cramped on medium and below, especially when the label is longer and wraps. While you'd be hard pressed to see that with English, it becomes very visible if you translate to a more verbose language such as Greek.
For example, the Authenticator Code plugin's label translates to «Κωδικός Επιβεβαίωσης Ταυτότητας» in Greek. This makes it wrap even on an 11" iPad, in portrait mode. I am not a designer but even I can tell that it's outright ridiculous having wrapped label text on a page that's mostly empty.
So, I am not changing that either.
When we login and switch to one time password login, we don't have a description
That's a fair point. I will take a look into it.
obviously not as I was wondering why the field was not present
I still need some text to put there as I have no idea what that text should read.
Between the two of us only you have experienced the confusion and understand why this happened and what would prevent it. That's why I am asking you for the text to put there. Can you please help?
UPDATE resolved
is it a code or a password. would be best to use just one term
@nikosdion Hey Nik, I wanted to ask where we are with this PR? Are there a lot more changes expected or are we nearly there?
@nikosdion The first beta is on Tuesday June 7th. Ideally I am building the packages tomorrow :) If the lang string is the only issue, we should be able to make it. Thank you.
@roland-d I fixed the lang strings (there were two of them). I think we can merge this PR as-is in the beta. Any fine-tuning, edge-polishing and yak-shaving can be implemented with other PRs against the 4.2-dev after it goes into beta. We won't have any language changes which is just about right for honouring the lang string beta freeze.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37912.
@roland-d Any fine-tuning, edge-polishing and yak-shaving can be implemented with other PRs against the 4.2-dev after it goes into beta.
@nikosdion I’m pretty much interested in the yak shaving part :-) How do you keep the yaks calm?
@richard67 Hm... Dunno about yaks, in my part of the world we have sheep. If you haven't had to stop your car for 10' because a herd of sheep is crossing the road you've not lived the rural life! Sheep are rather docile and will gladly take a shaving, especially when the weather gets hot as it tends to do over here around May. Before you ask, nope, I don't have the skills to shear sheep. My relationship with sheep extends to observing them grazing across the hill and using their digestive byproduct as fertiliser (excellent fertiliser for trees, but do it early in Spring when you can keep your windows closed, TRUST ME ON THAT).
@nikosdion It seems that you planned to make a change to the issue #37912 (comment) (did not see the commit and can not check in reality on a PC).
@Kostelano We can add this after the merge of this PR. We already have the language strings for this feature, it's just adding it to the output.
I have tested this item
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37912.
| Status | Pending | ⇒ | Ready to Commit |
RTC
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37912.
| Labels |
Added:
?
|
||
| Status | Ready to Commit | ⇒ | Fixed in Code Base |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-06-04 07:01:44 |
| Closed_By | ⇒ | roland-d |
Thanks everybody for this great feature.
Thank you for the merge!
@nikosdion It seems that you planned to make a change to the issue #37912 (comment) (did not see the commit and can not check in reality on a PC).
Who wants to make a PR? @Kostelano ? Or @nikosdion ?
it si the same with other methods
Thank you @richard67
@nikosdion, give me a couple of free minutes.
I can't figure out the parameter "Force Enable" for plugin Authentication Code by Email.
I carefully read the description, tried to implement the situation in this way: I created a user, created an authentication method for him (fixed password), then enabled the above parameter in plugin Authentication Code by Email. I'm trying to log in, I switch to an alternative method (suppose I forgot the fixed code and did not save the emergency passwords), but I do NOT have a "forced method" (authentication code by mail).
What am I doing wrong, or perhaps I misinterpreted the parameter description? Thank you in advance for your response.
Should I automatically add the Authentication Code by Email as an option for all users? Useful to provide a fallback to users who have lost access to their main authenticator and haven't kept a copy of the backup codes at the expense of some degree of control and security.
@Kostelano There were two missing lines not copied over from LoginGuard. Thank you for the heads up! I submitted #38029 to fix that.
I am not creating a bug because it does not pull on an error (probably), but I write here.
If we install some module separately, then with a high degree of probability we want to use it and it will still take its position in the template.
If we install a whole package, which may include a component/plugins/modules, then we won't necessarily use it all.
By default, the module occupies the NONE position. The same is immediately displayed in the parameters of the component users ---> MFA. Can we remove this position from the array of all positions for this reason?
@Kostelano I disagree. Sometimes you may want to create a module in the None position to display it in an article which in itself is displayed by a module in another, published position. If you disallow the None module position to be selected in this multi-select control that article would appear without the referenced module.
Remember, this only controls which modules will be loaded by Joomla (in fact, all modules are loaded and modules in module positions NOT listed in this control are forcibly UNLOADED using some black magic fuckery I am doing). It does not really control which module positions will be displayed.
Hi
I have the problem the allowed frontend/backend module positiions stay empty here
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/37912.
Enable all 5 plugins. Create one of the methods for yourself. Then disable all plugins (if you disable only the configured method - the problem does not reproduce), log out and try to log in.
Warning: Invalid argument supplied for foreach() in C:\OpenServer\domains\joomla4\administrator\components\com_users\src\Helper\Mfa.php on line 159