[UX] Login settings: Consolidate all "Limit login attempts" settings.

[klonos]

The form in admin/config/people/login has the following groups of settings:

• User login (username, email, or both)
• Limit login attempts by IP address
• Limit login attempts by user
• Log excessive failed login attempts ("roque", free-floating checkbox)

I propose that we group the 3 last items together, under a single "Failed login attempts settings" fieldset, which should be collapsed by default (since these settings are kinda advanced, and the defaults should just work for most cases).

Having the fieldset collapsed by default should also leave more room in this form for the settings that we are looking to introduce as part of #3309, which are less advanced.

We should also remove instances of "user" from labels and help text. There's quite a few of them in this form.

[klonos]

PR ready for initial UI review (tests still running): https://github.com/backdrop/backdrop/pull/4763

Before/after screenshot (the new fieldset is collapsed by default - expanded here): ...and how the form looks by default, with the fieldset collapsed:

There are many text changes, because:

• there were several instances of "user" instead of "user account"
• text that would apply to multiple elements was consolidated and moved to the main fieldset instead
• help text that was stating the obvious or simply repeating the same text as in the respective field labels was removed
• the period that was previously added to the Log excessive failed login attempts. checkbox label needed to be removed (we are not adding periods to labels)

[avpaderno]

I like that the If there are excessive failed login attempts, the offending IP address or user account will be temporarily blocked. sentence is placed before the relative settings, and not at the bottom of the form as it is now. I would not expect that the description for the Log excessive login attempts checkbox would also explain what all those settings are (and that is probably the reason I have never read that description).

[klonos]

I was also thinking to re-word the help text for the two radio options.

Current:

• More secure; more likely to block user accounts.
• Less secure; less likely to block user accounts.

Considering this instead (bolding the bits that are important):

• More secure; but more likely to block user accounts.
• Less likely to block user accounts, but less secure.

And some visuals:

...basically emphasizing the bits that would otherwise be a warning for caution.

[klonos]

...now that I'm thinking about it, I liked how the original versions of these texts mentioned the words "lock out" instead of "block". I had to change it to "block" because I changed "users" to "user accounts", but if we changed that to "people" instead, it could be "lock people out" (of the site) instead of "block user accounts". I think I will change the PR to that instead.

[klonos]

...PR updated. Here's before/after of that specific part of the form:

I initially changed the radio label to Identify people attempting to log in, using but that ("identifying people") didn't sound right. So I went with Identify the source of failed login attempts, using instead in the end. Ideas for anything better than that?

[klonos]

...I also don't really like less secure, especially considering the fact that we have that as the default. Perhaps say less strict or less accurate instead? Thoughts?

[izmeez]

Grouping the failed login items into a fieldset and having the info at the top of the fieldset look good.

The issue of other detailed wording changes may be more contentious. I don't really like more secure and less secure and not even sure they are true. I prefer the phrase more strict and less strict but again I don't know that it's true that combined ID & IP address is less.

[avpaderno]

I would rather not use secure nor strict. More likely to lock people out of the site and Less likely to lock people out of the site should be sufficient.

[klonos]

Thanks for the feedback @izmeez and @kiamlaluno 🙏🏼

What do you thing about using more accurate/less accurate? ...if these don't sound good, then I'm also inclined to go with @kiamlaluno's suggestion and just omit the more secure/less secure altogether. ...would love some feedback from others on that.

[avpaderno]

To make my previous comment clearer: I understand that secure means avoiding that people who try to guess the password used for an account can successfully do that. I would just avoid to define a method more secure than the other, and say that a method could (more likely) lock out people who try to access their own account.

[klonos]

Perhaps, we should just say exactly that(?):

Makes guessing passwords harder, but is more likely to lock people out of the site.

...I don't think that we should say the opposite ("makes guessing passwords easy") for the other option though. Perhaps throwing the word "even" into the mix would improve things:

Makes guessing passwords even harder, but is more likely to lock people out of the site.

[klonos]

...although "makes guessing passwords harder" is not a very accurate description of what this setting does from a technical point of view 🤔 ...it doesn't make guessing harder per se - it blocks more guessing attempts.

[avpaderno]

That's correct: It just limits the number of wrong passwords can be entered. As for Makes guessing passwords harder, that is not necessary true: In the case I know the password associated with an account is the person's date birthday, neither one or the other method makes guessing the password harder for me.

[klonos]

Thanks for all the feedback @kiamlaluno 🙏🏼 ...it is really helpful. I think I'll wait for another person or two to chime in, and then will most likely remove the mentions of "more secure"/"less secure" entirely (unless people think that they do actually have value and are accurate descriptions, or can suggest any better alternative).

[klonos]

...one final thought with regards to that setting specifically: should we move the default option (UID + IP combo) to be the first of the two available options? It feels odd the way it is placed last now.