I am currently running a local Sitecore at version 7.2 rev 140526 and Web Forms for Marketers at 2.4 rev 150619. I am currently experiencing an SMTP failure to authenticate error when using the WFFM SendEmailMessage default save action.
After some investigation, I discovered that this is because WFFM's internal EmailAttributes class that stores the SMTP config (that comes from either the web.config or the Parameters field on the SaveAction itself, as per their documentation) was using an old SMTP password that was changed over a year ago.
That is to say, the values retrieved by the following two lines of code were different despite the fact that the mail server password in the webconfig and Parameters fields specify the same value:
var configPassword = Sitecore.Configuration.Settings.GetSetting("MailServerPassword");
// EmailAttributes.Password
var basePassword = Password;
This old password that is returned when accessing the EmailAttributes.Password field is not present in the web.config in either the solution or the Sitecore/Website directory nor is it present in my local showconfig. Futhermore, the old password is not present in the Parameters field of the default WFFM SendEmailMessage save action and the following Sitecore query executed against Core, Master and Web database yields no results:
fast://*[#Parameters = '%fooBar%']
It is also worth noting that if the value contained in the configPassword variable (which is the correct password) is used to overwrite the value contained in the EmailAttribute's Password field (e.g. Password = configPassword) mail is sent successfully and there is no authentication error with the SMTP server.
We have a custom SendEmail save action that inherits from Sitecore.Form.Submit.SendMessage, overrides the Execute method, manipulates the fields collection and calls base.Execute() and emails are sent successfully.
Also, in WFFM v 2.3.0 rev 130118 there is no SMTP failure to authenticate exception thrown when using the default SendEmailMessage save action provided by WFFM when using the same SMTP configuration in the web.config file and config injected into the Parameters field of the SendEmailMessage save action.
I am at a loss for how/why the EmailAttributes.Password field would be getting a value that is not present in config, not coming from the Paremeters field on the SaveAction in sitecore, and isn't configured manually in the SMTP Email IIS module.
Any insight would be much appreciated!
The issue is most likely due to the way that the WFFM parameters are stored. Unfortunately the save action is not stored as a reference to the original when you add an action to a form. What actually happens is the parameters are copied from the parameters field of the Save Action to the Save Actions field on the form when it is added. Since it is a copy and not a reference, changing the parameters on the original save action does not change any existing forms using that save action.
You can verify this by going to the the form in Content Editor, go to View ribbon and ensure Standard Fields and Raw Values are both checked. Then check the Save Actions field under the Submit section. You should find the password within the XML in the <parameters> node.
There are 2 options to fix this:
Delete the send email save action from your form and add it in again
Edit the XML from the Save Actions field to remove the Password
Related
I've checked the docs, but so far haven't found how to change the default admin password in ActiveMQ Artemis 2.27.1 created when using the artemis create command.
Here are the contents of the etc/login.config:
activemq {
org.apache.activemq.artemis.spi.core.security.jaas.PropertiesLoginModule required
debug=false
reload=true
org.apache.activemq.jaas.properties.user="artemis-users.properties"
org.apache.activemq.jaas.properties.role="artemis-roles.properties";
};
These are the contents of artemis-users.properties:
admin = ENC(1024:EE12ADBFA02C8DB4AF73E22F44C9BD2C12861A2CD01186CA07A874FAA824A757:BA04C1C3F55B0F68EFB2804BB001EAC2C5105EC1662DCBF96E158F9DA3E0C1BB9D8ECA2FF77BBD391938BCB1E69D865322981AB134BF81B1378AFBBE9C040350)
#admin = ENC(1024:389da8e6db1d6dc50b300ec99ea5604a)
I tried masking the the password as described here, (this is the commented admin), but got invalid credentials when I tried to login after restarting the server.
I generated it like this:
./artemis mask <plaintextPassword>
By default credentials are stored in the etc/artemis-users.properties. Each line represents a user and its password in the format:
<user> = <password>
Passwords are hashed by default and stored using the ENC() syntax, but you can use plain text password if you want. Also, by default any changes to artemis-users.properties and artemis-roles.properties are reloaded automatically (since reload=true in login.config) so there's no need to restart the broker.
More details are available in the documentation for the PropertiesLoginModule.
If you want to update the file manually with a hashed password you need to use the following command in the bin directory:
$ ./artemis mask --hash <password>
This is documented in the "Masking Passwords" chapter.
Additionally, if you have at least one valid, working user account with the manage permission or if you have anonymous login enabled then you can use the user commands to list, add, remove, and reset users. As before, more details can be found in the documentation.
In my WSO2 Identy Server (v5.8.0), i have added one custom attribute named XXX.
Then, in my web client application, I invoke /scim2/Users service to create new user inside IDS.
I successfully create user with correct name, surname, email, phone number and so on, but my custom field is not updated in my user content store.
By other hand, if I update field by data entry and read my user from IDS, I can see my custom attribute XXX correctly.
Can someone help me ?
One of the following reasons could be caused not to update custom attributes via scim2/Users endpoint.
Once you add a new local claim and if you want to access/modify its value using SCIM endpoint it should be mapped to scim claim dialect. Follow the steps in extending scim user claims doc in https://docs.wso2.com/display/IS580/Extending+SCIM+2.0+User+Schemas
If the above step is correctly configured, check the request payload whether the attribute is correctly defined in the payload. If the attribute is not defined in the expected format, WSO2 IS ignores those attributes.
When you trying to update the value via login to the management console and view the user profile through the management console doesn't involve the SCIM APIs. You are directly updating the local claim in the WSO2 local claim dialect. If you have followed the doc mention is step 1 and that attribute has a value, GET /scim2/Users/{user-id} should return the attribute in the response.
I'm using WSO2-IS version 5.8.0. I have successfully established ReadOnly connection with my Active Directory LDAP Server, but faced another problem:
I have configured LDAP for users like in example below:
Connection URL: ldaps://your.domain.com:686
Connection Name: CN=John Dee,OU=Users,DC=your,DC=domain,DC=com
Connection Password: mygoodpassword
User Search Base: OU=Users
Username Attribute: sAMAccountName
User Search Filter: (&(objectClass=user)(sAMAccountName=?))
User List Filter: (objectClass=person)
Everything works fine, users were added and I was able to login to my services using SSO.
The problem has appeared when I have tried to add Roles(Groups from AD):
Below a parameters which I used for AD groups adding:
Group Search Base: OU=Groups
Group Name Attribute: sAMAccountName
Group Search Filter: (&(objectClass=group)(sAMAccountName=?))
Group List Filter: (objectClass=group)
Membership attribute: member
Afterwards I have clicked on "Update" button, and User Store has disappeared, but .xml file on the server still exists.
I tried to configure ReadOnly LDAP using .xml on the server, but after any edits in the User Store from UI - the same issue appears.
I found a solution for the problem. By unknown reason when I initially installed all parameters in UI, but there was a problem in XML file:
/usr/lib64/wso2/wso2is/5.8.0/repository/deployment/server/userstores/Example.xml:
Initial value:
<Property name="GroupNameSearchFilter">(&(objectClass=group)(sAMAccountName=?))</Property>
After my changes:
<Property name="GroupNameSearchFilter">(&(objectClass=group)(sAMAccountName=?))</Property>
I have restarted wso2 service and now everything work fine.
However, it seems the problem in UI fields verification, I don't know why wso2 UI didn't validate fields in User Stores.
I have a WFFM in my application which sends a thank you email after registration in my site. I have changed some email body text and it stopped working not sure why. Is there any way to check the issue or upload the template again?
The question is very light on details but on WFFM 8.0 this is a known bug, if you check the logs then the following error will be present:
Exception: System.FormatException
Message: The specified string is not in the form required for an e-mail address.
The problem is due to a bug in the Mail Message editor, which causes any dynamic user input fields in the TO, FROM or CC fields to be incorrectly encoded with double brackets, e.g. from [User Email] to [[User Email]]. When the field is expanded and passed to the send email pipeline the additional set of brackets around the whole email, causing the FormatException.
The error will occur even if you just edit the message body and not even touch the recipient fields.
This is a known bug and the fix can be found in this Sitecore Knowledge base article: Error submitting form when using Send Email action in WFFM. Alternatively contact Sitecore Support and quote ticket number 402562.
I am following this guide to allow the users to reset the password using email. The problem is when the user requests "password reset link" for multiple times, the old links generated are not invalidated. (Password can be reset using either the latest link or old links).
Is there any parameter I can set to invalidate the old links?
There is a property file called identity-mgt.properties which you can find in the /repository/conf/identity/ directory.
In this property file, there is a property called Notification.Expire.Time which you could use to set the confirmation code expire time in munites.
Notification.Expire.Time denotes the expiration time of the confirmation code. Even in a notification recovery scenario a confirmation code is generated. If notification is done via email, the link sent to the user for verification will include the confirmation code. Therefore, once the user clicks that link, the confirmation code will be verified. Thus, you can use this property to validate the link.
Currently, generated confirmation codes will invalidate only once user change his password successfully. So as you have mentioned user will be able to recover his password using any confirmation code he has retrieved. And when user successfully change the password, all the confirmation codes generated before that would be invalidated. This is the default behaviour for now and we don't have a configuration to change that.