-
Bug
-
Resolution: Fixed
-
Low (View bug fix roadmap)
-
6.2.1, 6.2.3, 6.3.15, 6.4
-
6.02
-
If you change the application password in Crowd, then when you go to edit this password in JIRA, you are forced to click "Test Settings" before you can "Save and Test". After clicking "Test Settings", the value of the password is then reset in the form to the previous value, so if you immediately click "Save and Test" after "Test Settings", the same password will be saved again.
Steps to Reproduce
- Set up an application in Crowd
- Connect JIRA to that application and check it's synchronising successfully
- Change the application password for that application in Crowd
- Disable and re-enable the directory in JIRA to immediately invalidate the session to Crowd
- Force a sync and watch it fail
- Edit the directory
- Enter the new password and click "Test Settings"
- After the test succeeds, click "Save and Test"
- Observe that the sync still fails
- Observe that the password value stored in cwd_directory_attribute table is still holding the old password
Expected Results
The value should be held after clicking "Test Settings", so that then clicking "Save and Test" will work correctly.
Actual Results
The value is lost, so the new password doesn't get saved
Workaround
After clicking "Test Settings", enter the new password again into the form before clicking "Save and Test"
Workaround for Delegated LDAP Connector
Do not click the 'Test Settings' button
- Open console in the browsers developer tools and run the following commands
AJS.$('#configure-delegating-ldap-form-submit').removeAttr("aria-disabled"); AJS.$('#configure-delegating-ldap-form-submit').removeAttr("disabled");
- That will allow you to click the 'Save and Test' button, with first clicking 'Test Settings'
- is a regression of
-
-
- Closed
-
-
-
- Closed
-
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- is related to
-
-
- Closed
-
-
EMBCWD-976 Loading...
[JRASERVER-38149] When editing an existing Crowd directory to change the application password, the application password value is reset to the old value after clicking "Test Settings"
I just lost a few hours of time due to this UI issue. It's incredibly confusing that you have to enter the directory password twice in order to update it. The only way I discovered that it wasn't actually saving the password was by creating a Support Zip and investigating the auth-cfg/directoryConfigurationSummary.txt file which showed (in plain text) that the application.password for my Crowd directory was clearly wrong. That showed me that the password clearly wasn't saving, so I started digging deeper and realized that I had to re-enter the password after clicking Test Settings (and before clicking Save & Test).
I had this issues in JIRA 6.2.7
I opened a ticket - JSP-212382
The following is my working around:
- Disable Directory (Delegated LDAP Authenication)
- Change password and click test
- Change password again, click test and save
- Verify by coming back in and clicking Test
- Enabled Directory
Harald Ommang, Verico AS
added a comment - I've been struggling for hours with JIRA 6.3.9. In the progress of migrating from a 6.0.3 installation over to new servers.
Imported the DB from 6.0.3 and changed the LDAP configuration there. And ran into the mess with this issue. No wonder no good clues were given in any logs...
Harald Ommang, Verico AS
added a comment - I've been struggling for hours with JIRA 6.3.9. In the progress of migrating from a 6.0.3 installation over to new servers.
Imported the DB from 6.0.3 and changed the LDAP configuration there. And ran into the mess with this issue. No wonder no good clues were given in any logs... 
Florian Hassanen
added a comment - fyi: this also affects confluence 5.6.3 
Hillary Garrett
added a comment - I am currently having this exact problem with LDAP. Our workaround was to change it directly in the MySQL database. We were actually a little shocked to see the password in the database in ASCII and not hashed in some way.
Hillary Garrett
added a comment - I am currently having this exact problem with LDAP. Our workaround was to change it directly in the MySQL database. We were actually a little shocked to see the password in the database in ASCII and not hashed in some way. Yes it looks like something related to my fix in embedded crowd.
This is also there in Confluence 5.7.
Just spent half a day bashing my head into this brick wall...