Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Minor
-
Resolution: Unresolved
-
Component/s: ldap-plugin
-
Environment:Jenkins 1.575
-
Similar Issues:
Description
When loading http://jenkinshost/configureSecurity/ we get an error pretending the given url for LDAP-Server would be wrong.
When clicking into the said field and out of it the verification request is triggered again and confirms as expected.
A deeper look into the executed request shows that the initial request is missing the value for the managerDN parameter, while the later request contains this information.
This might relate to JENKINS-18126
Attachments
Issue Links
- relates to
-
JENKINS-43388 Provide a "Test" button that allows verification of the LDAP settings before application to prevent lockout
-
- Closed
-
Activity
thank you for your answer
i´m not speaking of the initial configuration but of editing a working configuration. so all values should be defined fine. i guess it might be a timing issue where the request is triggered before the managerDN value is assigned to the form field.
i didn´t check the code but it sounds plausible to me that, while looping through all currend values that have to be assigned the form fields, the verification request is triggered as soon as the server url value is assigned, while the managerDN value yet isn´t. so the method that generates the url to be requestet reads the value out of the managerDN field that is still empty.
in this case the solution would be to delay the generation of the request url to a point where all values where assigned to their form fields.
in reference to your suggested workaround it would probably also solve our problem to simply reverse the loop that assignes the initial form values, so that the managerDN field is filled before the url field. on the other hand this could affect other requests that might rely on the current assignment order.
also i guess it would mask the issue to trigger the verification request when the managerDN value is assigned as well. this should result in two requests where the first failes while the second is successful and thereby hides the fail of the first attempt. you might want to consider doing so anyway as this would also result in reflecting changes done to the managerDN field. as right now the changes done to managerDN are not "live-tested" in the way that changes to the url it self are.
François Thieke
added a comment - thank you for your answer
i´m not speaking of the initial configuration but of editing a working configuration. so all values should be defined fine. i guess it might be a timing issue where the request is triggered before the managerDN value is assigned to the form field.
i didn´t check the code but it sounds plausible to me that, while looping through all currend values that have to be assigned the form fields, the verification request is triggered as soon as the server url value is assigned, while the managerDN value yet isn´t. so the method that generates the url to be requestet reads the value out of the managerDN field that is still empty.
in this case the solution would be to delay the generation of the request url to a point where all values where assigned to their form fields.
in reference to your suggested workaround it would probably also solve our problem to simply reverse the loop that assignes the initial form values, so that the managerDN field is filled before the url field. on the other hand this could affect other requests that might rely on the current assignment order.
also i guess it would mask the issue to trigger the verification request when the managerDN value is assigned as well. this should result in two requests where the first failes while the second is successful and thereby hides the fail of the first attempt. you might want to consider doing so anyway as this would also result in reflecting changes done to the managerDN field. as right now the changes done to managerDN are not "live-tested" in the way that changes to the url it self are. By the time the request is made, the field value was not yet been set by you, so the error message is correct about that. And it just doesn't update when changing a different field.
Workaround: Start with auth, then only fill in server.
In order to set proper expectation, I have unassigned Kohsuke from this tickets.
Currently there is no Default assignee in the LDAP plugin, any contributions will be appreciated.