)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":11589,"name":"Harry Rybacki","email":"hrybacki@redhat.com","username":"hrybacki"},"change_message_id":"51a82ad2909b5cf14b0ead64f2a853171da3f827","unresolved":false,"context_lines":[{"line_number":4,"context_line":"Commit:     Adam Young \u003cayoung@redhat.com\u003e"},{"line_number":5,"context_line":"CommitDate: 2018-09-25 14:56:32 -0400"},{"line_number":6,"context_line":""},{"line_number":7,"context_line":"Replace UUID with sha256 generator for Federated users"},{"line_number":8,"context_line":""},{"line_number":9,"context_line":"Note that this is tested via"},{"line_number":10,"context_line":"tox -e py35 -- keystone.tests.unit.test_shadow_users"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"3f79a3b5_d13975cf","line":7,"updated":"2018-09-25 19:12:50.000000000","message":"Can we expand on the motivation for this change a bit?","commit_id":"bcb67140e391d036d82d84fb827985167d8f7e69"},{"author":{"_account_id":8482,"name":"Colleen Murphy","email":"colleen@gazlene.net","username":"krinkle"},"change_message_id":"df3094911138525ca566b95f087b01df8645902f","unresolved":false,"context_lines":[{"line_number":20,"context_line":""},{"line_number":21,"context_line":"Longer IDs show up in some of the Federation tests"},{"line_number":22,"context_line":""},{"line_number":23,"context_line":"closes-bug: 1794530"},{"line_number":24,"context_line":""},{"line_number":25,"context_line":"Change-Id: Ica21c54c1fcc9b44e4935718c8903237d0857120"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":3,"id":"3f79a3b5_3219b5d0","line":23,"updated":"2018-09-26 14:14:50.000000000","message":"It looks like there\u0027s already a bug for this https://bugs.launchpad.net/keystone/+bug/1641639","commit_id":"70960c433723945b2fa5968d1f6b323059e1a356"}],"keystone/identity/shadow_backends/sql.py":[{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"d3e04bb2f9972231c80766037d9ca64789ea69a0","unresolved":false,"context_lines":[{"line_number":36,"context_line":"                        \u0027local_id\u0027: federated_dict[\u0027unique_id\u0027],"},{"line_number":37,"context_line":"                        \u0027entity_type\u0027: \u0027user\u0027}"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"        public_id \u003d PROVIDERS.id_generator_api.generate_public_ID(local_entity)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"        user \u003d {"},{"line_number":42,"context_line":"            \u0027id\u0027: public_id,"}],"source_content_type":"text/x-python","patch_set":2,"id":"3f79a3b5_1c705d73","line":39,"range":{"start_line":39,"start_character":8,"end_line":39,"end_character":79},"updated":"2018-09-26 02:45:49.000000000","message":"As we refactor this and clean up the generator code, this functionality should be lifted up to the manager. Ideally we shouldn\u0027t be doing PROVIDER calls in the drivers.\n\nThis is a special case. If we have reason to roll another patch, please add a comment/TODO to this effect.","commit_id":"4b67b38ad0531d74cd49e267ae7b773072abecd4"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"3db89d8aeeadf77ec38a09e25abe776fa0dfcd1b","unresolved":false,"context_lines":[{"line_number":36,"context_line":"                        \u0027local_id\u0027: federated_dict[\u0027unique_id\u0027],"},{"line_number":37,"context_line":"                        \u0027entity_type\u0027: \u0027user\u0027}"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"        public_id \u003d PROVIDERS.id_generator_api.generate_public_ID(local_entity)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"        user \u003d {"},{"line_number":42,"context_line":"            \u0027id\u0027: public_id,"}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_3711f25d","line":39,"range":{"start_line":39,"start_character":20,"end_line":39,"end_character":79},"updated":"2018-10-30 12:43:36.000000000","message":"I\u0027m not really a fan of calling up to the managers from a backend. Can we move this up a layer instead?","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"},{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"a43b8f4c2ac788c81b573aec4db6a2cafd2b3db1","unresolved":false,"context_lines":[{"line_number":36,"context_line":"                        \u0027local_id\u0027: federated_dict[\u0027unique_id\u0027],"},{"line_number":37,"context_line":"                        \u0027entity_type\u0027: \u0027user\u0027}"},{"line_number":38,"context_line":""},{"line_number":39,"context_line":"        public_id \u003d PROVIDERS.id_generator_api.generate_public_ID(local_entity)"},{"line_number":40,"context_line":""},{"line_number":41,"context_line":"        user \u003d {"},{"line_number":42,"context_line":"            \u0027id\u0027: public_id,"}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_0fc4d641","line":39,"range":{"start_line":39,"start_character":20,"end_line":39,"end_character":79},"in_reply_to":"3f79a3b5_3711f25d","updated":"2018-11-02 16:55:07.000000000","message":"I tend to agree. However, I think this is a much bigger change that should come as a followup. Ideally we should have the ID generation moved upwards. Either it can be done before or after.","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c15552243784fed787dd47d9365fcc9c9e80157e","unresolved":false,"context_lines":[{"line_number":94,"context_line":"            user_refs \u003d sql.filter_limit_query(model.User, query, hints)"},{"line_number":95,"context_line":"            return [identity_base.filter_user(x.to_dict()) for x in user_refs]"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    def get_federated_user(self, idp_id, protocol_id, unique_id):"},{"line_number":98,"context_line":"        # NOTE(notmorgan): Open a session here to ensure .to_dict is called"},{"line_number":99,"context_line":"        # within an active session context. This will prevent lazy-load"},{"line_number":100,"context_line":"        # relationship failure edge-cases"}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_96d94ff2","line":97,"range":{"start_line":97,"start_character":54,"end_line":97,"end_character":63},"updated":"2018-10-24 15:25:46.000000000","message":"If federated users already exist in a deployment, new federated users will have a hashed ID and older federated users will have a uuid4().hex, right?","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"},{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"a7206212535bd71ff1b779df3ce7c9c10fd9d0d2","unresolved":false,"context_lines":[{"line_number":94,"context_line":"            user_refs \u003d sql.filter_limit_query(model.User, query, hints)"},{"line_number":95,"context_line":"            return [identity_base.filter_user(x.to_dict()) for x in user_refs]"},{"line_number":96,"context_line":""},{"line_number":97,"context_line":"    def get_federated_user(self, idp_id, protocol_id, unique_id):"},{"line_number":98,"context_line":"        # NOTE(notmorgan): Open a session here to ensure .to_dict is called"},{"line_number":99,"context_line":"        # within an active session context. This will prevent lazy-load"},{"line_number":100,"context_line":"        # relationship failure edge-cases"}],"source_content_type":"text/x-python","patch_set":7,"id":"3f79a3b5_07c98ba9","line":97,"range":{"start_line":97,"start_character":54,"end_line":97,"end_character":63},"in_reply_to":"3f79a3b5_96d94ff2","updated":"2018-10-24 16:48:43.000000000","message":"That is the idea.","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"}],"keystone/tests/unit/test_v3_federation.py":[{"author":{"_account_id":2903,"name":"Morgan Fainberg","email":"morgan.fainberg@gmail.com","username":"mdrnstm"},"change_message_id":"8785a5e5d8830abf30331c53da79bb0b41112e09","unresolved":false,"context_lines":[{"line_number":2878,"context_line":""},{"line_number":2879,"context_line":"    def test_federated_unscoped_token(self):"},{"line_number":2880,"context_line":"        resp \u003d self._issue_unscoped_token()"},{"line_number":2881,"context_line":"        self.assertEqual(268, len(resp.headers[\u0027X-Subject-Token\u0027]))"},{"line_number":2882,"context_line":"        self.assertValidMappedUser(resp.json_body[\u0027token\u0027])"},{"line_number":2883,"context_line":""},{"line_number":2884,"context_line":"    def test_federated_unscoped_token_with_multiple_groups(self):"}],"source_content_type":"text/x-python","patch_set":5,"id":"3f79a3b5_46665757","line":2881,"updated":"2018-10-03 22:19:38.000000000","message":"Realistically we need to pick a value that can be consistent here. I\u0027m ok with this change as is, but lets stake a line in the ground and say \"we limit fernets to X size\" and set that value somewhere in test.core -- we can still change it but I don\u0027t like the explicit \"X Size\" checks.","commit_id":"afd05e7919ce802c8aceaafadee7d1fa31face98"}],"releasenotes/notes/bug-1641639-b9accc163e61ca15.yaml":[{"author":{"_account_id":15054,"name":"wangxiyuan","email":"wangxiyuan1007@gmail.com","username":"wangxiyuan"},"change_message_id":"2bc15c7edfae54c848595b24a54009b2cf6281a4","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"fixes:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    A Federated user gets an entry in the shadow-users table. This"},{"line_number":5,"context_line":"    entry has a unique ID. It was generated using a UUID. This fix"},{"line_number":6,"context_line":"    changes to reuse the mechanism for LDAP, where the ID is generated"}],"source_content_type":"text/x-yaml","patch_set":7,"id":"3f79a3b5_c7c65a9d","line":3,"updated":"2018-10-24 08:16:40.000000000","message":"should add the bug link here","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c15552243784fed787dd47d9365fcc9c9e80157e","unresolved":false,"context_lines":[{"line_number":1,"context_line":"---"},{"line_number":2,"context_line":"fixes:"},{"line_number":3,"context_line":"  - |"},{"line_number":4,"context_line":"    A Federated user gets an entry in the shadow-users table. This"},{"line_number":5,"context_line":"    entry has a unique ID. It was generated using a UUID. This fix"},{"line_number":6,"context_line":"    changes to reuse the mechanism for LDAP, where the ID is generated"}],"source_content_type":"text/x-yaml","patch_set":7,"id":"3f79a3b5_76f59351","line":3,"in_reply_to":"3f79a3b5_c7c65a9d","updated":"2018-10-24 15:25:46.000000000","message":"Yep - per the documented convention here: \n\nhttps://docs.openstack.org/keystone/latest/contributor/release-notes.html","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c15552243784fed787dd47d9365fcc9c9e80157e","unresolved":false,"context_lines":[{"line_number":5,"context_line":"    entry has a unique ID. It was generated using a UUID. This fix"},{"line_number":6,"context_line":"    changes to reuse the mechanism for LDAP, where the ID is generated"},{"line_number":7,"context_line":"    from the domain ID + the local id of the user (an attribute that"},{"line_number":8,"context_line":"    uniquely ids the user from the IdP). This generator is specified"},{"line_number":9,"context_line":"    by the configuration file. Now Both LDAP and Federated Ids are"},{"line_number":10,"context_line":"    generated the same way. It also means that Federated IDs can be"},{"line_number":11,"context_line":"    kept in sync between two independtent Keystone servers."}],"source_content_type":"text/x-yaml","patch_set":7,"id":"3f79a3b5_f632030e","line":9,"range":{"start_line":8,"start_character":41,"end_line":9,"end_character":29},"updated":"2018-10-24 15:25:46.000000000","message":"We can give the specific location here, too:\n\n  ``keystone.conf [identity_mapping] generator``","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"},{"author":{"_account_id":5046,"name":"Lance Bragstad","email":"lbragstad@redhat.com","username":"ldbragst"},"change_message_id":"c15552243784fed787dd47d9365fcc9c9e80157e","unresolved":false,"context_lines":[{"line_number":8,"context_line":"    uniquely ids the user from the IdP). This generator is specified"},{"line_number":9,"context_line":"    by the configuration file. Now Both LDAP and Federated Ids are"},{"line_number":10,"context_line":"    generated the same way. It also means that Federated IDs can be"},{"line_number":11,"context_line":"    kept in sync between two independtent Keystone servers."}],"source_content_type":"text/x-yaml","patch_set":7,"id":"3f79a3b5_f6644322","line":11,"range":{"start_line":11,"start_character":29,"end_line":11,"end_character":41},"updated":"2018-10-24 15:25:46.000000000","message":"independent*","commit_id":"89d37dad9b71fe69cc3c0107127b3fa20b1643e5"}]}