Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-28474

Confusing Chrome password manager behavior on ldap auth settings page

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • ldap-plugin
    • None
    • Linux, Chrome 43
      Jenkins 1.606
      LDAP plugin 1.11

      With ldap plugin configured with no "manager DN" or password, visit configureSecurity with Chrome 43 that has Jenkins auth data remembered. Click "Advanced" on the LDAP settings and notice that Chrome has auto-filled the ldap "Manager DN" and "Manager Password" fields with the user's Jenkins login data.

      If the LDAP server requires these to be empty, loading configureSecurity and clicking save/apply, which should be a no-op, will break the configuration and the user might not realize what's going on.

      What most likely is going on is that Chrome is trying to be too helpful in detecting where a login / password field combination is. If I remove the stored Jenkins password from Chrome, it is not auto-filled, re-remembering it makes the problem return.

      As much as this could be regarded as a Chrome problem, it would be useful if the plugin did not trigger this behavior, especially as it happens on a hidden field. Note that Chrome blissfully ignores autocomplete=off, so JENKINS-3586 is no longer helpful.

          [JENKINS-28474] Confusing Chrome password manager behavior on ldap auth settings page

          Daniel Beck added a comment -

          Note that Chrome blissfully ignores autocomplete=off

          Do you know of a possible solution to this issue then?

          Daniel Beck added a comment - Note that Chrome blissfully ignores autocomplete=off Do you know of a possible solution to this issue then?

          Not quite. It appears that a lot of this is working "as intended" which doesn't help. See for example:
          https://code.google.com/p/chromium/issues/detail?id=370363
          https://code.google.com/p/chromium/issues/detail?id=352347

          As per the above it could probably be worked around by using autocomplete="chromeplease" but that's just ugly. Perhaps autocomplete="new-password" as supported since https://code.google.com/p/chromium/issues/detail?id=375333 would be better.

          Tomasz Śniatowski added a comment - Not quite. It appears that a lot of this is working "as intended" which doesn't help. See for example: https://code.google.com/p/chromium/issues/detail?id=370363 https://code.google.com/p/chromium/issues/detail?id=352347 As per the above it could probably be worked around by using autocomplete="chromeplease" but that's just ugly. Perhaps autocomplete="new-password" as supported since https://code.google.com/p/chromium/issues/detail?id=375333 would be better.

          Daniel Beck added a comment -

          Thanks for the links. This is ridiculous. Not sure what could be done from Jenkins. I doubt that adding a 'fake' hidden login form for the autocomplete to do its things would be a great idea. (If that workaround works, wouldn't that invalidate all the arguments against respecting autocomplete=off?)

          Daniel Beck added a comment - Thanks for the links. This is ridiculous. Not sure what could be done from Jenkins. I doubt that adding a 'fake' hidden login form for the autocomplete to do its things would be a great idea. (If that workaround works, wouldn't that invalidate all the arguments against respecting autocomplete=off?)

          As per the above it seems that using autocomplete with a value other than "off" might work

          Tomasz Śniatowski added a comment - As per the above it seems that using autocomplete with a value other than "off" might work

          I've actually experienced the issue of being locked out from Jenkins exactly like described here but with:

          • Jenkins 2.46.2
          • LDAP plugin 1.15
          • Chrome 58.0.3029.110

          I think the severity of this issue should be raised because it can't be acceptable being locked out from Jenkins only because the auto-fill is enabled.

          Moreover, it seems that a merge request that fix this is pending.

          Fabrizio Cucci added a comment - I've actually experienced the issue of being locked out from Jenkins exactly like described here but with: Jenkins 2.46.2 LDAP plugin 1.15 Chrome 58.0.3029.110 I think the severity of this issue should be raised because it can't be acceptable being locked out from Jenkins only because the auto-fill is enabled. Moreover, it seems that a merge request that fix this is pending.

          Oleg Nenashev added a comment -

          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.

          Oleg Nenashev added a comment - 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.

            Unassigned Unassigned
            tsniatowski Tomasz Śniatowski
            Votes:
            2 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: