)]}'
{"/COMMIT_MSG":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"3ae4bf569689c140d1387d6ba571f071f7964175","unresolved":true,"context_lines":[{"line_number":9,"context_line":"This patch undoes the changes made in"},{"line_number":10,"context_line":"https://review.opendev.org/c/openstack/horizon/+/997715 to unblock the"},{"line_number":11,"context_line":"gate, and instead monkey-patches the oslo.policy enforcers to disable"},{"line_number":12,"context_line":"the scope checks, as they are pointless in the context of horizon."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"This should give us more accurate results than the original fix, that"},{"line_number":15,"context_line":"caucht and ignore the InvalidScope exception, because the scope check"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"72d71089_6da538ad","line":12,"range":{"start_line":12,"start_character":30,"end_line":12,"end_character":39},"updated":"2026-07-21 15:55:06.000000000","message":"In case you use domain scope to access API in the backend services then it may not be accepted unless API explicitly declare policy for domain scope now. So even if horizon expects that the API can be executed, it mat not function as expected unless the backend service agree.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"6d669bfc87f49cddc7b813096695c5f3084e76cc","unresolved":true,"context_lines":[{"line_number":9,"context_line":"This patch undoes the changes made in"},{"line_number":10,"context_line":"https://review.opendev.org/c/openstack/horizon/+/997715 to unblock the"},{"line_number":11,"context_line":"gate, and instead monkey-patches the oslo.policy enforcers to disable"},{"line_number":12,"context_line":"the scope checks, as they are pointless in the context of horizon."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"This should give us more accurate results than the original fix, that"},{"line_number":15,"context_line":"caucht and ignore the InvalidScope exception, because the scope check"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"5782c244_e49f9da4","line":12,"range":{"start_line":12,"start_character":30,"end_line":12,"end_character":39},"in_reply_to":"36044641_41c3b5c4","updated":"2026-07-22 18:09:21.000000000","message":"If I understand the Horizon use case here, which is kind of a pre-API call to decide if menu/action buttons need to be displayed or not. For that, horizon need to validate the policy from oslo.policy directly instead of going to the project API call.\n\nIn that case, I agree that scope checks can make it fail early before policy rules are actually checked. I see two solutions in this case:\n\n1. Make scope checks later in oslo.policy so that Horizon can make sure it is a scope check failure or policy rule authorization. This can make policy checks slow when it should be rejected due to invalid scope only. I will keep this option as last option.\n\n2. Horizon can feed the scope into the token so that oslo.policy scope checks will pass, and policy rule check_str can be checked. Tempest does the same kind of things based on the information from token. I think this is what we can try here. Below is how Tempest feed the scope on token\n  - https://github.com/openstack/tempest/blob/406633de5471ef4834c65d2ec5a682d3251251a7/tempest/lib/common/dynamic_creds.py#L142-L151","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"36adfb4bb7450c1643749a222a24c35fd0937040","unresolved":true,"context_lines":[{"line_number":9,"context_line":"This patch undoes the changes made in"},{"line_number":10,"context_line":"https://review.opendev.org/c/openstack/horizon/+/997715 to unblock the"},{"line_number":11,"context_line":"gate, and instead monkey-patches the oslo.policy enforcers to disable"},{"line_number":12,"context_line":"the scope checks, as they are pointless in the context of horizon."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"This should give us more accurate results than the original fix, that"},{"line_number":15,"context_line":"caucht and ignore the InvalidScope exception, because the scope check"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"b54739f1_135247e2","line":12,"range":{"start_line":12,"start_character":30,"end_line":12,"end_character":39},"in_reply_to":"5782c244_e49f9da4","updated":"2026-07-22 18:27:34.000000000","message":"even oslo.policy does the identification of scope based on information in token which makes things easy - https://github.com/openstack/oslo.policy/blob/69890e47048014944c80aae27f82941a598fb573/oslo_policy/policy.py#L1131-L1140\n\n        # Check the scope of the operation against the possible scope\n        # attributes provided in `creds`.\n        if creds.get(\u0027system\u0027):\n            token_scope \u003d \u0027system\u0027  # noqa: S105\n        elif creds.get(\u0027domain_id\u0027):\n            token_scope \u003d \u0027domain\u0027  # noqa: S105\n        else:\n            # If the token isn\u0027t system-scoped or domain-scoped then\n            # we\u0027re dealing with a project-scoped token.\n            token_scope \u003d \u0027project\u0027  # noqa: S105","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"72a4904718e4510c4bd3618107191486579e3bd7","unresolved":true,"context_lines":[{"line_number":9,"context_line":"This patch undoes the changes made in"},{"line_number":10,"context_line":"https://review.opendev.org/c/openstack/horizon/+/997715 to unblock the"},{"line_number":11,"context_line":"gate, and instead monkey-patches the oslo.policy enforcers to disable"},{"line_number":12,"context_line":"the scope checks, as they are pointless in the context of horizon."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"This should give us more accurate results than the original fix, that"},{"line_number":15,"context_line":"caucht and ignore the InvalidScope exception, because the scope check"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"36044641_41c3b5c4","line":12,"range":{"start_line":12,"start_character":30,"end_line":12,"end_character":39},"in_reply_to":"72d71089_6da538ad","updated":"2026-07-21 17:58:00.000000000","message":"We don\u0027t use oslo.policy to call the APIs. We only call it to check whether to display menu items and action buttons. No token is involved in that, and there is no scope -- different API calls made by the same view may in fact use different scopes, when they are eventually called by the user. Oslo.policy is making assumptions that simply make no sense in UI application, ans is forcing us to write complex and brittle code just to satisfy some artificial check that has no advantage to the user whatsoever.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"5c21c2e9dda24d347afebb7064a3e228115cca10","unresolved":true,"context_lines":[{"line_number":9,"context_line":"This patch undoes the changes made in"},{"line_number":10,"context_line":"https://review.opendev.org/c/openstack/horizon/+/997715 to unblock the"},{"line_number":11,"context_line":"gate, and instead monkey-patches the oslo.policy enforcers to disable"},{"line_number":12,"context_line":"the scope checks, as they are pointless in the context of horizon."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"This should give us more accurate results than the original fix, that"},{"line_number":15,"context_line":"caucht and ignore the InvalidScope exception, because the scope check"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"2dd87e82_36c1d773","line":12,"range":{"start_line":12,"start_character":30,"end_line":12,"end_character":39},"in_reply_to":"78e51b17_67ff7685","updated":"2026-07-23 17:58:07.000000000","message":"\u003e \u003e Horizon can feed the scope into the token so that oslo.policy scope checks will pass, and policy rule check_str can be checked.\n\u003e \n\u003e At the point where we are calling the policy checks (while displaying the menus, and while displaying the actions in tables, etc.) we don\u0027t know which token will be used. In fact, we often don\u0027t even know which API calls will be made when we check for menu items.\n\nPlease check my comment in other file I think that will solve the issue as Horizon can just pass the \u0027system\u003dNone\u0027 and no domain_id in project token and oslo.policy will calculate the scope based on token parameter\n\n- https://review.opendev.org/c/openstack/horizon/+/998096/comment/ec997cef_a9bb190b/\n\n- https://review.opendev.org/c/openstack/horizon/+/998096/comment/fe000884_401911e9/","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"35a12eb7ff5f860270ac9992619710c3a9ddf996","unresolved":true,"context_lines":[{"line_number":9,"context_line":"This patch undoes the changes made in"},{"line_number":10,"context_line":"https://review.opendev.org/c/openstack/horizon/+/997715 to unblock the"},{"line_number":11,"context_line":"gate, and instead monkey-patches the oslo.policy enforcers to disable"},{"line_number":12,"context_line":"the scope checks, as they are pointless in the context of horizon."},{"line_number":13,"context_line":""},{"line_number":14,"context_line":"This should give us more accurate results than the original fix, that"},{"line_number":15,"context_line":"caucht and ignore the InvalidScope exception, because the scope check"}],"source_content_type":"text/x-gerrit-commit-message","patch_set":1,"id":"78e51b17_67ff7685","line":12,"range":{"start_line":12,"start_character":30,"end_line":12,"end_character":39},"in_reply_to":"b54739f1_135247e2","updated":"2026-07-23 09:31:40.000000000","message":"\u003e Make scope checks later in oslo.policy so that Horizon can make sure it is a scope check failure or policy rule authorization. This can make policy checks slow when it should be rejected due to invalid scope only. I will keep this option as last option.\n\nIt really depends on what kind of usage you expect. If 99% of your policy checks have the wrong scope (as is currently the case in Horizon), then making the scope check early and short-circuiting the entire function totally makes sense, and speeds up the whole thing considerably. However, if the wrong scope is a rare anomaly (as I think it should be), then actually moving it to the end should speed up all the other cases, where the scope is correct, but some other thing doesn\u0027t match, and you can reject it early and avoid checking the scope entirely.\n\nBut really, python is not so slow that a pair of if statements and dictionary look-ups would make a noticeable difference in either case, especially compared to the time needed to handle a http request. I\u0027m always wary of doing such micro-optimization without measuring the overall performance first and confirming that this is indeed a bottleneck.\n\n\u003e Horizon can feed the scope into the token so that oslo.policy scope checks will pass, and policy rule check_str can be checked.\n\nAt the point where we are calling the policy checks (while displaying the menus, and while displaying the actions in tables, etc.) we don\u0027t know which token will be used. In fact, we often don\u0027t even know which API calls will be made when we check for menu items.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"}],"/PATCHSET_LEVEL":[{"author":{"_account_id":28522,"name":"Hervé Beraud","email":"herveberaud.pro@gmail.com","username":"hberaud"},"change_message_id":"303923c4ef14d32638981141531db1a0de59f4a9","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"828fdf40_e4999395","updated":"2026-07-22 09:16:06.000000000","message":"Based on the changes and of various responses to comments, this patch LGTM","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"6d669bfc87f49cddc7b813096695c5f3084e76cc","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"2937e3e9_34a87ca4","updated":"2026-07-22 18:09:21.000000000","message":"I think we need to go with either of the solutions I mentioned in line. patching oslo.policy like this is not recommended.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":35133,"name":"Jan Jasek","email":"jjasek@redhat.com","username":"janjasek"},"change_message_id":"f0e7e6412d53f387868a63e7d1cfec745cea34ce","unresolved":false,"context_lines":[],"source_content_type":"","patch_set":1,"id":"b5964de5_cfef11e3","updated":"2026-07-21 12:45:43.000000000","message":"Looks good to me, thanks for the quick fix and cleanup patch @openstack@dopieralski.pl!","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"}],"openstack_auth/policy.py":[{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"b67ae39e03e61c205b2bcfca8d1a9ab4e52e93f2","unresolved":true,"context_lines":[{"line_number":119,"context_line":"            conf \u003d _get_policy_conf(policy_file, policy_dirs)"},{"line_number":120,"context_line":"            enforcer \u003d policy.Enforcer(conf)"},{"line_number":121,"context_line":"            enforcer.suppress_default_change_warnings \u003d True"},{"line_number":122,"context_line":"            enforcer._enforce_scope \u003d lambda *args, **kwargs: True"},{"line_number":123,"context_line":"            _load_default_rules(service, enforcer)"},{"line_number":124,"context_line":"            try:"},{"line_number":125,"context_line":"                enforcer.load_rules()"}],"source_content_type":"text/x-python","patch_set":1,"id":"c99c080f_5480e4ff","line":122,"range":{"start_line":122,"start_character":12,"end_line":122,"end_character":66},"updated":"2026-07-21 15:53:39.000000000","message":"I\u0027d add large todo for this hack.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"93526d55304924cc792daca19c794b841d397526","unresolved":true,"context_lines":[{"line_number":119,"context_line":"            conf \u003d _get_policy_conf(policy_file, policy_dirs)"},{"line_number":120,"context_line":"            enforcer \u003d policy.Enforcer(conf)"},{"line_number":121,"context_line":"            enforcer.suppress_default_change_warnings \u003d True"},{"line_number":122,"context_line":"            enforcer._enforce_scope \u003d lambda *args, **kwargs: True"},{"line_number":123,"context_line":"            _load_default_rules(service, enforcer)"},{"line_number":124,"context_line":"            try:"},{"line_number":125,"context_line":"                enforcer.load_rules()"}],"source_content_type":"text/x-python","patch_set":1,"id":"b342e87d_98f6525e","line":122,"range":{"start_line":122,"start_character":12,"end_line":122,"end_character":66},"in_reply_to":"37f88dc5_40bcdc4a","updated":"2026-07-22 09:41:17.000000000","message":"In case we really have to void scope check then we should implement a native interface to oslo.policy and should use it instead of patching its method externally.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"321940bcf4055f26e53d34c1da894490c310a5bb","unresolved":true,"context_lines":[{"line_number":119,"context_line":"            conf \u003d _get_policy_conf(policy_file, policy_dirs)"},{"line_number":120,"context_line":"            enforcer \u003d policy.Enforcer(conf)"},{"line_number":121,"context_line":"            enforcer.suppress_default_change_warnings \u003d True"},{"line_number":122,"context_line":"            enforcer._enforce_scope \u003d lambda *args, **kwargs: True"},{"line_number":123,"context_line":"            _load_default_rules(service, enforcer)"},{"line_number":124,"context_line":"            try:"},{"line_number":125,"context_line":"                enforcer.load_rules()"}],"source_content_type":"text/x-python","patch_set":1,"id":"c473f144_322b5e51","line":122,"range":{"start_line":122,"start_character":12,"end_line":122,"end_character":66},"in_reply_to":"b342e87d_98f6525e","updated":"2026-07-22 10:20:57.000000000","message":"Is there any realistic chance of that happening, considering how much energy just went into removing that option?","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"6d669bfc87f49cddc7b813096695c5f3084e76cc","unresolved":true,"context_lines":[{"line_number":119,"context_line":"            conf \u003d _get_policy_conf(policy_file, policy_dirs)"},{"line_number":120,"context_line":"            enforcer \u003d policy.Enforcer(conf)"},{"line_number":121,"context_line":"            enforcer.suppress_default_change_warnings \u003d True"},{"line_number":122,"context_line":"            enforcer._enforce_scope \u003d lambda *args, **kwargs: True"},{"line_number":123,"context_line":"            _load_default_rules(service, enforcer)"},{"line_number":124,"context_line":"            try:"},{"line_number":125,"context_line":"                enforcer.load_rules()"}],"source_content_type":"text/x-python","patch_set":1,"id":"4b1b0ae7_59e6e8a2","line":122,"range":{"start_line":122,"start_character":12,"end_line":122,"end_character":66},"in_reply_to":"c473f144_322b5e51","updated":"2026-07-22 18:09:21.000000000","message":"I will not suggest doing it. I commented in the commit message about possible solutions, but this patching is really not recommended.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"72a4904718e4510c4bd3618107191486579e3bd7","unresolved":true,"context_lines":[{"line_number":119,"context_line":"            conf \u003d _get_policy_conf(policy_file, policy_dirs)"},{"line_number":120,"context_line":"            enforcer \u003d policy.Enforcer(conf)"},{"line_number":121,"context_line":"            enforcer.suppress_default_change_warnings \u003d True"},{"line_number":122,"context_line":"            enforcer._enforce_scope \u003d lambda *args, **kwargs: True"},{"line_number":123,"context_line":"            _load_default_rules(service, enforcer)"},{"line_number":124,"context_line":"            try:"},{"line_number":125,"context_line":"                enforcer.load_rules()"}],"source_content_type":"text/x-python","patch_set":1,"id":"37f88dc5_40bcdc4a","line":122,"range":{"start_line":122,"start_character":12,"end_line":122,"end_character":66},"in_reply_to":"c99c080f_5480e4ff","updated":"2026-07-21 17:58:00.000000000","message":"What would be the action to do for it? Fork oslo.policy?","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"eab1790167f709ceddadc2a8393e8ccf517f92b9","unresolved":true,"context_lines":[{"line_number":248,"context_line":"        if scope in enforcer:"},{"line_number":249,"context_line":"            # this is for handling the v3 policy file and will only be"},{"line_number":250,"context_line":"            # needed when a domain scoped token is present"},{"line_number":251,"context_line":"            if scope \u003d\u003d \u0027identity\u0027 and domain_credentials:"},{"line_number":252,"context_line":"                # use domain credentials"},{"line_number":253,"context_line":"                if not _check_credentials(enforcer[scope],"},{"line_number":254,"context_line":"                                          action,"},{"line_number":255,"context_line":"                                          target,"},{"line_number":256,"context_line":"                                          domain_credentials):"},{"line_number":257,"context_line":"                    return False"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"            # use project credentials"},{"line_number":260,"context_line":"            if not _check_credentials(enforcer[scope],"},{"line_number":261,"context_line":"                                      action, target, credentials):"},{"line_number":262,"context_line":"                return False"},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"        # if no policy for scope, allow action, underlying API will"},{"line_number":265,"context_line":"        # ultimately block the action if not permitted, treat as though"}],"source_content_type":"text/x-python","patch_set":1,"id":"81a1c0a8_62a8cf78","line":262,"range":{"start_line":251,"start_character":0,"end_line":262,"end_character":28},"updated":"2026-07-22 09:44:13.000000000","message":"Hmm I wonder if this is expected to switch the credential scope according to the expectation by the backend services. Then it\u0027s not very clear why InvalidScope would be raised. Is there any case where domain scope is used for non-keystone policy rules ?","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"321940bcf4055f26e53d34c1da894490c310a5bb","unresolved":true,"context_lines":[{"line_number":248,"context_line":"        if scope in enforcer:"},{"line_number":249,"context_line":"            # this is for handling the v3 policy file and will only be"},{"line_number":250,"context_line":"            # needed when a domain scoped token is present"},{"line_number":251,"context_line":"            if scope \u003d\u003d \u0027identity\u0027 and domain_credentials:"},{"line_number":252,"context_line":"                # use domain credentials"},{"line_number":253,"context_line":"                if not _check_credentials(enforcer[scope],"},{"line_number":254,"context_line":"                                          action,"},{"line_number":255,"context_line":"                                          target,"},{"line_number":256,"context_line":"                                          domain_credentials):"},{"line_number":257,"context_line":"                    return False"},{"line_number":258,"context_line":""},{"line_number":259,"context_line":"            # use project credentials"},{"line_number":260,"context_line":"            if not _check_credentials(enforcer[scope],"},{"line_number":261,"context_line":"                                      action, target, credentials):"},{"line_number":262,"context_line":"                return False"},{"line_number":263,"context_line":""},{"line_number":264,"context_line":"        # if no policy for scope, allow action, underlying API will"},{"line_number":265,"context_line":"        # ultimately block the action if not permitted, treat as though"}],"source_content_type":"text/x-python","patch_set":1,"id":"a99c7509_65d4c39b","line":262,"range":{"start_line":251,"start_character":0,"end_line":262,"end_character":28},"in_reply_to":"81a1c0a8_62a8cf78","updated":"2026-07-22 10:20:57.000000000","message":"As I mentioned before, this code is nine years old and there is nobody left on the Horizon team who understands why it is the way it is. It\u0027s not even clear to us what is the \"desired\" way it should be working. We always passed domain_id in the credentials for all calls -- you can see that on line 294, so apparently oslo.policy was always assuming a domain scope. I believe this code just changes which domain, in case the user has picked a different domain than default at login.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"36adfb4bb7450c1643749a222a24c35fd0937040","unresolved":true,"context_lines":[{"line_number":290,"context_line":"                             \u0027username\u0027: user.username,"},{"line_number":291,"context_line":"                             \u0027project_id\u0027: user.project_id,"},{"line_number":292,"context_line":"                             \u0027tenant_id\u0027: user.project_id,"},{"line_number":293,"context_line":"                             \u0027project_name\u0027: user.project_name,"},{"line_number":294,"context_line":"                             \u0027domain_id\u0027: user.user_domain_id,"},{"line_number":295,"context_line":"                             \u0027is_admin\u0027: user.is_superuser,"},{"line_number":296,"context_line":"                             \u0027roles\u0027: roles}"}],"source_content_type":"text/x-python","patch_set":1,"id":"ec997cef_a9bb190b","line":293,"range":{"start_line":293,"start_character":62,"end_line":293,"end_character":63},"updated":"2026-07-22 18:27:34.000000000","message":"as this is project scope token you can make system\u003dNone explicitly so that oslo.policy will treat this as project scoped token.\n\n        user._credentials \u003d {\u0027user_id\u0027: user.id,\n                             \u0027username\u0027: user.username,\n                             \u0027project_id\u0027: user.project_id,\n                             \u0027tenant_id\u0027: user.project_id,\n                             \u0027project_name\u0027: user.project_name,\n                             \u0027system\u0027: None,\n                             \u0027is_admin\u0027: user.is_superuser,\n                             \u0027roles\u0027: roles}","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"b67ae39e03e61c205b2bcfca8d1a9ab4e52e93f2","unresolved":true,"context_lines":[{"line_number":291,"context_line":"                             \u0027project_id\u0027: user.project_id,"},{"line_number":292,"context_line":"                             \u0027tenant_id\u0027: user.project_id,"},{"line_number":293,"context_line":"                             \u0027project_name\u0027: user.project_name,"},{"line_number":294,"context_line":"                             \u0027domain_id\u0027: user.user_domain_id,"},{"line_number":295,"context_line":"                             \u0027is_admin\u0027: user.is_superuser,"},{"line_number":296,"context_line":"                             \u0027roles\u0027: roles}"},{"line_number":297,"context_line":"    return user._credentials"}],"source_content_type":"text/x-python","patch_set":1,"id":"fe000884_401911e9","line":294,"range":{"start_line":294,"start_character":29,"end_line":294,"end_character":62},"updated":"2026-07-21 15:53:39.000000000","message":"I think what we should revert atm is the fallback logic in _check_credentials, while we should still avoid adding domain_id in case project scope credential is expected (adding domain_id to the credential means you request domain scope. that has been the core concept in policy management in oslo.policy).\n\nAlso do we know which exact operation horizon expects to be executable with domain scope ?","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":9816,"name":"Takashi Kajinami","email":"kajinamit@oss.nttdata.com","username":"kajinamit"},"change_message_id":"93526d55304924cc792daca19c794b841d397526","unresolved":true,"context_lines":[{"line_number":291,"context_line":"                             \u0027project_id\u0027: user.project_id,"},{"line_number":292,"context_line":"                             \u0027tenant_id\u0027: user.project_id,"},{"line_number":293,"context_line":"                             \u0027project_name\u0027: user.project_name,"},{"line_number":294,"context_line":"                             \u0027domain_id\u0027: user.user_domain_id,"},{"line_number":295,"context_line":"                             \u0027is_admin\u0027: user.is_superuser,"},{"line_number":296,"context_line":"                             \u0027roles\u0027: roles}"},{"line_number":297,"context_line":"    return user._credentials"}],"source_content_type":"text/x-python","patch_set":1,"id":"aed05311_6cda0e28","line":294,"range":{"start_line":294,"start_character":29,"end_line":294,"end_character":62},"in_reply_to":"1c1c97fd_d768056f","updated":"2026-07-22 09:41:17.000000000","message":"\u003e We are not validating API calls, we are checking whether to display a menu item or an action button\n\nI don\u0027t understand this point. Isn\u0027t the visibility determined based on the policy rules provided by each services like nova ?\n\nFor example nova no longer allows domain scoped access to its resources. Evaluating visibility for nova resources based on domain scoped credential is no longer valid and can cause false result. In case horizon users project scope token for a specific service then it should use the project scope credential to evaluate the policy rules brought by services, which defines their expected scope.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"36adfb4bb7450c1643749a222a24c35fd0937040","unresolved":true,"context_lines":[{"line_number":291,"context_line":"                             \u0027project_id\u0027: user.project_id,"},{"line_number":292,"context_line":"                             \u0027tenant_id\u0027: user.project_id,"},{"line_number":293,"context_line":"                             \u0027project_name\u0027: user.project_name,"},{"line_number":294,"context_line":"                             \u0027domain_id\u0027: user.user_domain_id,"},{"line_number":295,"context_line":"                             \u0027is_admin\u0027: user.is_superuser,"},{"line_number":296,"context_line":"                             \u0027roles\u0027: roles}"},{"line_number":297,"context_line":"    return user._credentials"}],"source_content_type":"text/x-python","patch_set":1,"id":"8ffab9cb_6b93ed5b","line":294,"range":{"start_line":294,"start_character":29,"end_line":294,"end_character":62},"in_reply_to":"802547af_5c76b4eb","updated":"2026-07-22 18:27:34.000000000","message":"ok but if you do not pass the domain_id in this user project token, then oslo.policy will consider this as a project-scoped token (wth system: None, as I commented in the above comment). I think if you remove the domain_id here then thigs will work. and if you need to use the domain scoped token then _domain_to_credentials can be used?\n\n- https://github.com/openstack/oslo.policy/blob/69890e47048014944c80aae27f82941a598fb573/oslo_policy/policy.py#L1140","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"321940bcf4055f26e53d34c1da894490c310a5bb","unresolved":true,"context_lines":[{"line_number":291,"context_line":"                             \u0027project_id\u0027: user.project_id,"},{"line_number":292,"context_line":"                             \u0027tenant_id\u0027: user.project_id,"},{"line_number":293,"context_line":"                             \u0027project_name\u0027: user.project_name,"},{"line_number":294,"context_line":"                             \u0027domain_id\u0027: user.user_domain_id,"},{"line_number":295,"context_line":"                             \u0027is_admin\u0027: user.is_superuser,"},{"line_number":296,"context_line":"                             \u0027roles\u0027: roles}"},{"line_number":297,"context_line":"    return user._credentials"}],"source_content_type":"text/x-python","patch_set":1,"id":"802547af_5c76b4eb","line":294,"range":{"start_line":294,"start_character":29,"end_line":294,"end_character":62},"in_reply_to":"aed05311_6cda0e28","updated":"2026-07-22 10:20:57.000000000","message":"Horizon does not expose the concept of a scope to the user. It\u0027s an internal implementation detail that is handled by the code that actually makes the API call. We make sure, when making an API call, to use the correct token for that call, with the right scope. But that happens in a completely different place than checking for whether to display menu items or buttons, and olso.policy is not involved in that.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8648,"name":"Radomir Dopieralski","email":"openstack@dopieralski.pl","username":"thesheep"},"change_message_id":"72a4904718e4510c4bd3618107191486579e3bd7","unresolved":true,"context_lines":[{"line_number":291,"context_line":"                             \u0027project_id\u0027: user.project_id,"},{"line_number":292,"context_line":"                             \u0027tenant_id\u0027: user.project_id,"},{"line_number":293,"context_line":"                             \u0027project_name\u0027: user.project_name,"},{"line_number":294,"context_line":"                             \u0027domain_id\u0027: user.user_domain_id,"},{"line_number":295,"context_line":"                             \u0027is_admin\u0027: user.is_superuser,"},{"line_number":296,"context_line":"                             \u0027roles\u0027: roles}"},{"line_number":297,"context_line":"    return user._credentials"}],"source_content_type":"text/x-python","patch_set":1,"id":"1c1c97fd_d768056f","line":294,"range":{"start_line":294,"start_character":29,"end_line":294,"end_character":62},"in_reply_to":"fe000884_401911e9","updated":"2026-07-21 17:58:00.000000000","message":"There is no scope at the point where horizon calls policy checks. The entire concept makes no sense in our context. We are not validating API calls, we are checking whether to display a menu item or an action button. In most cases we don\u0027t even know what API end point will be eventually called by the user, not to mention what scope the token for that call will have -- that is handled by Horizon automatically in a completely different place, where the API calls are actually happening, and oslo.policy is not involved in that in any way.","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"},{"author":{"_account_id":8556,"name":"Ghanshyam Maan","display_name":"Ghanshyam Maan","email":"gmaan.os14@gmail.com","username":"ghanshyam"},"change_message_id":"36adfb4bb7450c1643749a222a24c35fd0937040","unresolved":true,"context_lines":[{"line_number":310,"context_line":"                domain_auth_ref.service_catalog.url_for(interface\u003dNone))"},{"line_number":311,"context_line":"            user._domain_credentials \u003d _user_to_credentials(domain_user)"},{"line_number":312,"context_line":""},{"line_number":313,"context_line":"            # uses the domain_id associated with the domain_user"},{"line_number":314,"context_line":"            user._domain_credentials[\u0027domain_id\u0027] \u003d domain_user.domain_id"},{"line_number":315,"context_line":""},{"line_number":316,"context_line":"        except Exception:"},{"line_number":317,"context_line":"            LOG.warning(\"Failed to create user from domain scoped token.\")"},{"line_number":318,"context_line":"            return None"}],"source_content_type":"text/x-python","patch_set":1,"id":"c9ebe04f_b68aaf9c","line":315,"range":{"start_line":313,"start_character":0,"end_line":315,"end_character":0},"updated":"2026-07-22 18:27:34.000000000","message":"for example here, oslo.policy should find the domain_id in creds and make token scope as domain so this should work as it is\n\n- https://github.com/openstack/oslo.policy/blob/69890e47048014944c80aae27f82941a598fb573/oslo_policy/policy.py#L1136","commit_id":"4e2dd42935af6267efec90f0dc463a74ce4f7a31"}]}