On both the TOTP account and TOTP login screens perform the following:
* Make the "Device name" label optional if user registers the first
TOTP credential. Make it mandatory otherwise,
* Denote the "Authenticator code" with asterisk, so it's clear it's
required field (always),
* Add sentence to Step 3 of configuring TOTP credential explaining
the user to provide device name label,
Also perform other CSS & locale / messages file changes, so the UX is
identical when creating OTP credentials on both of these pages
Add a corresponding testcase
Also address issues pointed out by mposolda's review. Thanks, Marek!
Signed-off-by: Jan Lieskovsky <jlieskov@redhat.com>
* KEYCLOAK-12469 KEYCLOAK-12185 Add CredentialTypeMetadata. Implement the screen with authentication mechanisms and implement Account REST Credentials API by use the credential type metadata
`npm install` is changed to run at build time, removing the need for commiting
the js modules, which are getting a bit silly in size with the introduction of
account2. Appropriate changes to prod-arguments.json are included that should
enable the product build to function properly. The community and developer
builds will continue to work without the proxying PNC provides.
This also changes the themes pom to work with more than one `package.json`
file. The only other one at the moment is for the new account console /
account2.
The documentation file has been updated.
Since we're building directly out of the source directories, it is possible in
a local dev environment for unintended files (e.g. old compiled .js files),
placed within src/main/resources/, to be included in the themes jar. This
shouldn't be a problem for actual builds though, which use a fresh clone.
Other small changes include refactoring the npm setup stuff to a global
definition, and the introduction of some properties to avoid duplicating path
definitions everywhere.
This commit does not include the churn that would result from deleting the
existing commited modules.
We now transfer the SMTP connection configuration via HTTP POST
request body parameters instead of URL parameters.
The improves handling of SMTP connection configuration values with
special characters. As a side effect sensitive information like SMTP
credentials are now longer exposed via URL parameters.
Previously the SMTP connection test send the connection parameters
as encoded URL parameters in combination with parameters in the request body.
However the server side endpoint did only look at the URL parameters.
Certain values, e.g. passwords with + or ; could lead to broken URL parameters.
The '+' in the allowed CORS origins does not replicate a '*' wildcard
from the Valid Redirect URIs. This information is now available in the
tooltip.
Also translated changed message into german.
vmuzikar