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").
Related
I know there's an earlier question with this subject here, but the OP never reported if the one answer resolved the issue. And since
Internal Server Error
is about as user-unfriendly as you can get, I would love to change this to something that feels more like "a message" than "an anvil dropped on your foot".
I have found one other SO post that tangentially relates to this issue (about that disappearing "duplicate emails" switch), but the problem is indeed not about whether or not to allow duplicate emails (or how to revive hidden admin controls) but how a very ordinary issue is communicated to the user - well, like how Keycloak notifies the user when they try and register with an existing username.
We're currently using the Docker version of Keycloak 12.0.4 with some customisations (a custom BCrypt module, some logging changes) running in IBM Cloud, using a Postgresql DB. We also added a custom theme & internationalisation. The same error occurs also when using the default Keycloak theme, though.
Here are our Login settings:
It turned out to be a configuration issue, but so deeply hidden that even the Keycloak developer who looked into the ticket I created had glossed over it.
The perpetrator was in menu Configure > Authentication > tab: Flows > choose dropdown: Registration > Profile validation radio button [o REQUIRED | o DISABLED]
This was set to disabled, which in effect prevents the duplicate email check in the registration form that the Realm settings > tab: Login form suggest are active. But then, of course, the database won't like that, with above-mentioned result.
This combination of settings should at least issue a warning, of course. I hope this will be corrected.
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!'')}"/>
How can I change what appears in the password reset email in laravel?
Like addressing the user with his name and show the password reset link etc.
Where is that email view located?
In Laravel 5.3 they changed the entire password reset code, so the given answer doesn't work anymore.
If you want to change the basic texts you should copy vendor/laravel/framework/src/Illuminate/Auth/Notifications/ResetPassword.php to some place in your own app (e.g. app/Notifications/ResetPassword.php), set the correct namespace and alter the texts as you wish. (don't alter the original ResetPassword.php since it's bad practice to alter files in the vendor folder!)
Then add a sendPasswordResetNotification method to the User class and make sure to reference to the appropriate ResetPassword class:
use App\Notifications\ResetPassword;
...
public function sendPasswordResetNotification($token) {
$this->notify(new ResetPassword($token));
}
If you want to change the rest of the mail template (which is used for all other mails as well) do the following:
Run php artisan vendor:publish
This will copy some blades from the vendor folder to the resources/views/vendor
The resources/views/vendor/notifications/email.blade.php is the one you want to change.
Hope this helps for people who got stuck in Laravel 5.3
Yes you can change the email template, which is located at
resources/views/emails/password.blade.php.
For customization pass an instance of User model to this view and echo out user name there like:
Hello, {{$user->username}}
//And Body of Reset link goes here
Update for laravel 5.3+
In updated laravel versions the code structure is revamped.
Password reset mail is now at vendor/laravel/framework/src/Illuminate/Auth/Notifications/ResetPassword.php
and its corresponding template is at:
resources/views/vendor/notifications/email.blade.php
So in order to customize it, you may need to:
Copy it to somewhere in your app's directory.
Set the proper namespace to refer to it.
Add a new method to User class & reference it to newly copied class
Customize.
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
I have a SSRS report in AX 2012 with a parameter, where Values is set to "Unbound Values" (Non-queried). In the popup for adding values, I have added a couple of lines with a value and a label like the following:
Value: MainAccountId,
Label: =Labels!#SYS135766
But when I preview (or run the report from AX after deploying), the text "Labels!#SYS135766" is shown as label in the dropdown on the dialog (instead of "Main account").
I have also tried with "Labels!#SYS135766" and "#SYS135766", but with no luck.
Does anyone know how to get the label ID translated to a text using unbound parameter values?
I know this is an old question, but still posting the possible answer hoping that it can help.
Cite from a post by Namukoa Isaac:
Reasons for the problem:
You have moved your AX service account from AX domain account from AX domain admin group
You have changed your SSRS service account password.
Solutions:
From the Start menu, point to All Programs, click the SQL Server folder, click theConfiguration Tools folder, and then click Reporting Services Configuration Manager.
In Reporting Services Configuration Manager click Connect and then click Service Account.
Set the password and then click Apply. The account and password should be the same as the Microsoft Dynamics AX proxy account.
System will ask you to backup your encrytion key, and then will some settings on the backhand.
Now Click the ServerName/MSSQLSERVER on the left top of the reporting server and then click Stop. Then click Start to restart the server. Always check with the SQL administrator and make sure no other users are connected to the server before you restart the server.