)]}'
{
  "commit": "5b48e362af72bfc960d64c2a69b005856af47863",
  "tree": "a08d19a004c2c6bdf38aae9213549a0ba5a1f080",
  "parents": [
    "54edc7aeef97df768477b5fa14f8fc45266a9c2e"
  ],
  "author": {
    "name": "Tim Burke",
    "email": "tim.burke@gmail.com",
    "time": "Tue May 26 16:21:45 2020 -0700"
  },
  "committer": {
    "name": "Tim Burke",
    "email": "tim.burke@gmail.com",
    "time": "Tue May 26 16:21:49 2020 -0700"
  },
  "message": "swift: Fix s3api/keystone interaction\n\nFor a long time, swift3 recommended a pipeline like\n\n   ... swift3 s3token authtoken keystoneauth ...\n\nThis led to inefficiencies where the proxy would first contact Keystone\nto validate the S3 signature and issue a token, then contact Keystone\n*again* to validate the token ID that was just issued.\n\nAfter s3token moved into the swift3 repo, it was improved to be able\nto put all of the headers into the WSGI environment that Swift\u0027s\nkeystoneauth middleware expected and the recommended pipeline was\nchanged to something like\n\n   ... authtoken s3api s3token keystoneauth ...\n\nAt the time, the old order would still work, it would just be less\nefficient. When support was added for Keystone v3, however, the new\norder became mandatory.\n\nAll of that happened before swift3 moved back into Swift as s3api, but\nthe pipeline placement problems are the same: Keystone users won\u0027t be\nable to use the S3 api with the current order.\n\nChange-Id: Id0659f109cc2fc12ddb371df0b26812ba8c442d9\nRelated-Change: I21e38884a2aefbb94b76c76deccd815f01db7362\nRelated-Change: Ic9af387b9192f285f0f486e7171eefb23968007e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "5be9e3575eb87cd9cf5f79ba3ec23297de5e77b0",
      "old_mode": 33188,
      "old_path": "lib/swift",
      "new_id": "b6c06c57bd3fa44bdb1a996a667839413cb664bf",
      "new_mode": 33188,
      "new_path": "lib/swift"
    }
  ]
}