I have a MAUI app (targeting iOS and Android) where I originally labeled the input fields as "Login" and "Password". This caused my installed password manager (LastPass) to pop up when I clicked in the "Login" field. However, I later decided to change the label of the "Login" field to "Account Number" to better match the naming conventions in my app's UI. Now, the password manager no longer automatically populates the "Account Number" field when I click in it (it still works when I click in the "Password" field).
<Entry
Placeholder="Account number"
Text="{Binding AccountNumber}"
AutomationId="AccountNumber"
Keyboard="Numeric" />
What is the best approach for getting MAUI possibly in conjunction with the underlying OS to recognize that this Entry is part of a Login/Password combination?
There is a IsPassword property but it causes the Entry to get masked which I don't want of course.
Related
In Keycloak, by default, users are able to change their first and last name in the account manager page. However, is it possible to disable this behavior?
Removing both fields in the theme results in those values not being sent and the form failing, and a hand-crafted POST request would defeat this method anyway.
I came across a similar problem and after reading this SO post, came to know that although you can disable/hide fields in ftl, you cannot disable form validation
For e.g I hid firstname field , but still cannot submit. Same was the result with disable as well:
I am not aware about disabling a particular field in some other way. However there is a workaround in which you can disable the entire account modification flow (Password can still be changed by Forgot Password option).
Bu default, account modification is enabled, but you can disable it for a particular realm by going to Realms -> Clients -> Account.
The result of this will be, the account page will be inaccessible:
You can remove the client role 'manage_account' for client 'account'.
In Keycloak, by default, users are able to change their first and last
name in the account manager page. Is it possible to disable this
behavior?
That can be done out-of-the-box (since Keycloak 14) by using the user profile functionality. First, the preview feature declarative-user-profile has to be enabled. For that start the server with:
--features=declarative-user-profile.
for the Quarkus version, or with
-Dkeycloak.profile.feature.declarative_user_profile=enabled
for the Wildfly version.
Bear in mind that:
Declarative User Profile is Technology Preview and is not fully
supported.
After starting the server with the aforementioned option, go to the Keycloak Admin Console and:
Go to the according Realm;
Go to the tab General;
Set User Profile enabled to ON
A new tab named User Profile (top right) will show up; click on it, and a set of configurable attributes will be shown.
Click on firstName, and then go to Permissions
In that section the permissions can be changed, accordingly. For example, if one sets Can user edit? to OFF, then when the user tries to change the firstName field in the account UI, that UI throws the following warning message:
The field First name is read only.
The same configuration can also be applied to the lastName attribute.
For the new Keycloak UI the workflow is exactly the same as the one I have just described. More information about the feature can be found in the official keycloak documentation (link)
You can use readonly property to disable email you can just change the following line:
<input type="text" class="form-control" id="email" name="email" readonly autofocus value="${(account.email!'')}"/>
In our installer we have multiple form components in which we hide some inner options in case the user have choose a specific option.
For example: In this screen - this is the default displayed options.
If the user choose different Authentication than the default SQL Server Authentication (Windows Authentication), than the installer hides the User Name & Password fields.
The problem happens while on upgrade. If the user previously choose the Windows Authentication option - the displayed screen will be like this:
It's not good, because while connecting with Windows Authentication the user input User Name & Password shouldn't be presented.
The Authentication input is defined as Combo-Box & have the Selection change script property like this:
if (selectedItem.equals("Windows Authentication")) {
((JTextField)formEnvironment.getFormComponentById("1418").getConfigurationObject()).setText("");
}
formEnvironment.getFormComponentById("1418").setVisible(!selectedItem.equals("Windows Authentication"));
formEnvironment.getFormComponentById("1677").setVisible(!selectedItem.equals("Windows Authentication"));
Basically I do understand why it won't work on upgrade - since it work by selection trigger, it won't be applied by default by the installer.
Is there any way applying this logic also upon upgrade?
You have to execute the same logic in the "Visibility script" properties of the "User name" and "Password" form components. You don't have the "selectedItem" parameter there, but you can query the variable that is bound to the "Authentication" form component, i.e. context.getVariable("variableName").
I use Keycloak 1.7.0-Final. The user must agree with Term and Conditions at registration.
I enabled "Terms and Conditions" in Authentication > Required actions, But nothing is shown on the registration page.
Also, I cannot find where to configure specific Terms and Condition files for each language.
Could you help?
Thank you.
By default existing users cannot have this page. You need to configure "Terms and Conditions" as "Default Action", then this will be applied by default for all new users.
For existing users, you need to put it manually unser "Users" > "Required actions".
Dont forget to customize the terms page under //themes/base/login/terms.ftl
You will see terms and conditions once the user has filled in the registration form and submits registration. You will have to override the terms.ftl (build your own theme) page if you want it customized and add your own messages locale - see Keycloak Docs - Themes ...
Enable terms and conditions
Regularly you must enable "Terms and Conditions" in Authentication > Required Actions as Enabled and Default Action. By default, this will show a dedicated page after the registration form page, using the template terms.ftl.
Using a checkbox for accepting terms and conditions in the registration page
For this purpose you must specify terms and conditions as Enabled, but not a Default Action. Otherwise you will see the dedicated page using terms.ftl. The problem here is that Keycloak has not a way to enable a checkbox to accept the terms and conditions in the registration page.
Nonetheless, doing a little of reverse engineering I found that when you accept the conditions the user will have an attribute called terms_and_conditions:
In order to reproduce this, you just need to create a custom attribute, named terms_and_conditions, with a numeric value, that seems to be the current time (Date.now()). Being that said, you need an HTML like:
<form>
<!-- other inputs -->
<div>
<input
type="checkbox"
id="terms"
name="user.attributes.terms_and_conditions"
value="<generated value, e.g. 1668029792010>" />
<label for="terms">I accept the terms and conditions</label>
</div>
<div>
<button type="submit">Create user</button>
</div>
</form>
This approach should also be valid if you create that user using the API.
i18n
If your are using a checkbox in the registration page, you can use the standard internationalisation strategy: using the messages properties files. It would probably have a link that reference the content of the "terms and conditions" in the current language. To get the lang code to construct the URL use ${locale.currentLanguageTag}.
Show a page for each language
On the other hand, if you want to use the typical Keycloak strategy using terms.ftl, then you must use the same layout as always and the text will change using the internationalisation.
But if the content of the terms and conditions is very long, then it should be better to create pages for each language, e.g. terms-en.ftl, terms-fr.ftl, etc. These ftl files will only contain the content in the corresponding language and they will be loaded using a code like:
<#include "terms-fr.ftl" />
e.g.
<#if (locale.currentLanguageTag!"en") == "en">
<#include "terms-en.ftl" />
<#else>
<#include "terms-es.ftl" />
</#if>
I hope this helps
You can use Keycloakify to create a theme.
Here is the section related to customizing Terms and conditions.
After having gotten more comfortable in Behaviour-Driven Developement using SpecFlow, I was wondering about having multiple scenarios for the same feature as follows:
Register.feature
Feature: Register a new user
In order to use the system,
one must register with the system
so that one gets authorized and may login
Scenario: Register a new user using valid credentials
Given I am on the registration page
When I have entered my desired username "UserName" and password "password"
And I have confirmed my password "password"
And I click the register button
Then I shall get confirmation that I am now a registered user
Beside the fact that my scenario might have gotten a bit too fat, one must also manage to validate other scenarios within the registration process such as:
Input user name is too short
Input password is too short
Input password doesn't contain numbers
Input password doesn't match the confirm password
Just to name a few. I have read about tags using SpecFlow Feature File so that I could perhaps do as follows:
#shorterPasswordProvided
Scenario: Register a user using a password that is too short
Given I am on the registration page
When I have entered my desired user name
And I have provided a password that is too short "allo"
And I click the Register button
Then I shall get an error message which mentions about the password minimum length
#noCredentialsAtAll
Scenario: Register a user using no credentials at all
Given I am on the registration page
When I click on the Register button with no credentials entered
Then I shall get an error message that says I have to fill all required fields in
Then, using the [BeforeScenario("myTag")] should do the trick.
The hooks allows for the execution of a subset of the tests to be executed following certain rules. So, a When method could then be executed with a predefined context, that is, the hook for which it was meant to be executed, and that is mentioned through the BeforeScenario or the like attribute.
Have I understood correctly, or am I in fog here?
Am I pushing too far?
Am I missing something?
Are all the "too short password", "no credentials provided" considered different usage scenarios, or are they something else which could only fit somewhere else in the code, like the unit tests themselves?
I mean, all those scenarios belongs to the Register feature, and as such, they shall be defined in the same Register.feature SpecFlow Feature File, right?
Ok, you have a couple of questions, so I'll work through them:
Then, using the [BeforeScenario("myTag")] should do the trick.
The BeforeScenario hook attribute is used to run some code before the scenario executes. It's often used to set-up the environment for the scenario (e.g. populate the test database with pertinent data); if used for this purpose, then the use of AfterScenario can also be used to clean-up the result of BeforeScenario.
The hooks allows for the execution of a subset of the tests to be
executed following certain rules. So, a When method could then be
executed with a predefined context
If I understand you correctly, you want to be able to use a tag to control when a step within the scenario can be run/not-run. This is not possible with SpecFlow's hook attributes; there is a BeforeStep hook but this only enables you to execute code before the step is run, it doesn't allow the step to be ignored.
Are all the "too short password", "no credentials provided" considered
different usage scenarios, or are they something else which could only
fit somewhere else in the code, like the unit tests themselves?
In your example, yes these are different scenarios for your "Register a new user" feature. If you are taking a strict BDD approach to your development, then with your "outside-in inside-out" development approach you will also implement unit tests (by falling back to TDD as part of the BDD process) which will also cover the "too short password" and "no credentials provided" validation.
As for your scenario:
When I have entered my desired username "UserName" and password "password"
Instead of using this, use:
When I enter my username "UserName"
And I enter my password "password"
By doing this you will be able to re-use "When I enter my password" in "Register a user using a password that is too short". This leads me onto:
And I have provided a password that is too short "allo"
There is no need to have a separate step which states the password is too short. Just re-use:
When I enter my password "allo"
For the same reason, don't use:
When I click on the Register button with no credentials entered
just reuse:
When I click on the Register button
This may be really simple, but I'm wondering how browsers that offer a 'remember your password' facility select the 'username' to save?
I'm working with some asp.net that is spitting out it's usual incomprehensible id/name values and the browser is offering to remember the registration form's 'postcode' field as the username, rather than the email address we'd like it to use.
Is the browser looking for a specific 'username' field name/id?
If there is no 'username' then what does it look for next?
Can we specify which field to use?
HTML does not offer any way for the web authors to support the password management mechanism. Browser basically have to guess which fields hold the username and the password. The latter is a bit easier due to the 'password' input type but not the solution itself, because that input type has no semantic value, it just says how user agents should render those fields.
As far as I can tell you, browsers would simply look for the first password field and then assume that the field before it is the username. So, in your case, you'll have to make sure that the password field strictly follows the username.
Another solution, which I am not sure would help the browsers do the right choice, is to turn off autocompletion on all the fields except the username and the password by setting the autocomplete attribute to off.