)]}'
{
  "commit": "a4ad77f9ec3292a7a6c2fb21689d672cf5db1f20",
  "tree": "d93f2dd859ede8da35efcd4fb41f29ace4337fc2",
  "parents": [
    "ffadc2e1878ce448127055e98299218574b103cf"
  ],
  "author": {
    "name": "Florian Zschocke",
    "email": "florian.zschocke@devolo.de",
    "time": "Fri Nov 11 19:22:17 2016 +0100"
  },
  "committer": {
    "name": "Florian Zschocke",
    "email": "florian.zschocke@devolo.de",
    "time": "Fri Nov 11 19:22:17 2016 +0100"
  },
  "message": "Clean up `LdapAuthProvider` to properly cover different LDAP search scenarios.\n\nGitblit allows in its configuration to set a \"manager\" user (and password) which can be used\nto search for the entry of a user wanting to log in. If they are both not set, an anonymous search\nis attempted. In the description below, when I say \"...as manager\", it is either as manager or\nanonymous.\nSo far the behaviour of Gitblit, with respect to binding to and searching in LDAP,\nhas been the following when a user logs in:\n\n**bind as manager**\n**search for the user**\n_bind as the user_\n_search for the teams_\n\nI\u0027ll call this code flow A.\n\nLater an additional configuration option had been added: `realm.ldap.bindpattern`.\n(PR gitblit/gitblit#162) It was meant to allow for not using a manager nor anonymous binds,\nby searching the directory as the user logging in.\nThis is done in code flow B:\n\n**bind as manager**\n_bind as user_\n_search for user_\n_search for teams_\n\nBoth A and B are flawed, I think. In A, it looks like a mistake to me that the binding stays with the\nuser after authentication. The problem that this causes is, that in LDAP server configurations\nwhere normal users are not allowed to read groups, the team information cannot be retrieved.\nI tried but failed to understand how B is supposed to work. There will always be a bind request\nas either anonymous or the manager DN when the LDAP connection is created. If neither is\npossible, the authentication process will fail and the user cannot log in.\n\nWhen synchronizing users and teams from LDAP, the following code flow is exercised:\n\nF:\n**bind as manager**\n**search for users**\n**search for teams**\n\nThis patch fixes both code flows by introducing a new flow.\n\nC:\n**bind as manager**\n**search for user**\n_bind as user to authenticate_\n**bind as manager**\n**search for teams**\n\nAnd it changes code flow B to the following code flow D:\n\n_bind as user_\n_search for user_\n_search for teams_\n\nWith code flows A, C, D and F the following usage (and authentication) scenarios are covered.\nThey are described from the view of a Gitblit administrator\u0027s intent and his LDAP setup.\n\n* Users and team should be snychronized with LDAP\n\tThis means anonymous or a fixed account must be able to read users and groups.\n\t\u003d\u003e covered by C and F\n\nAs the above allows for authentication and is required for synchronisation, all the others below\ndo not cover synchronization.\n\n* No anonymous binding allowed and no special manager binding required\n\tThis means that users must be able to read user an group entries.\n\t\u003d\u003e covered by D\n\n* The user DN needs to be searched, e.g. because they are not all under the same parent DN.\n\tThis means that anonymous or a fixed account must be able to read users.\n\t\t-- anonymous or the \"manager\" account can also read groups\n\t\t\t\u003d\u003e covered by C\n\t\t-- anonymous or the \"manager\" account cannot read groups but a user can\n\t\t\t\u003d\u003e covered by A\n\nI therefore believe that the new code will cover all common use cases. The implementation\neither directly binds as the user, when `bindpattern` is not empty, or it binds anonymous or\nagainst the manger DN to search for the user DN entry.\n\nIf it directly bound against the user DN, the user is already authenticated. It will then only check\nthat the user DN it found in the search is identical to the one it is currently bound against. If it\nwas bound against a manager DN (or anonymously) it will bind against the found user DN to\nauthenticate the user logging in, and will then rebind against the manager DN.\n\nWhen searching for groups in LDAP, if the search fails with a result code other than SUCCESS,\nthe implementation will bind against the user DN, if it isn\u0027t already bound against it. It will then\nrepeat the search for groups under the user authorization. This is to keep backwards\ncompatible with the original behaviour A, in order to not break cases where the LDAP setup\nwould deny a manager account to search for groups but allow it for normal users.\n\nTo achieve this the implementation introduces an internal `LdapConnection` class that wraps\nthe connection and keeps bind state, so that a rebind as a user is possible.\nThis also fixes a resource leak where the connection was not closed in case that the initial bind\nas the manager account did not succeed.\n\nThis commit would fix gitblit/gitblit#920\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "cc772e7b4ddf94471f2ee1a5517baf73cee28217",
      "old_mode": 33188,
      "old_path": "src/main/java/com/gitblit/auth/LdapAuthProvider.java",
      "new_id": "e1dec48fb6b4813f4f003b9e6943346ae3b29f81",
      "new_mode": 33188,
      "new_path": "src/main/java/com/gitblit/auth/LdapAuthProvider.java"
    }
  ]
}