vincbeck commented on issue #51971: URL: https://github.com/apache/airflow/issues/51971#issuecomment-3006202680
Hey @zach-overflow . Thanks for looking into it, I agree with you, these docs can be way better and happy to see you are willing to do it :) Let me try to answer the questions. > What role do the resource identifiers in airflow.security.permissions play in the auth manager? None. `airflow.security.permissions` is deprecated and should not be used. The reason why we keep them is they are widely used by users in plugins and it is hard to delete them. But trust, I'd like them to be removed, so please do not use them. > How do the airflow.api_fastapi.auth.managers.models.resource_details class definitions relate to similarly named identifiers in airflow.security.permission? In `resource_details` we define 3 kind of classes: - Details classes (e.g. `ConnectionDetails`). These classes are used to pass additional information about the resource when calling the `is_authorized_*` method. Example: `is_authorized_connection(method="GET", user=user, details=ConnectionDetails(conn_id="default"))` allows to know whether the user has access to read the connection "default" - `AccessView`. Is used to provide information which view the user is trying to access. Example: `is_authorized_view(access_view=AccessView.PROVIDERS)` checks whether the user has accept to the view providers in the UI. - `DagAccessEntity`. Gives more information, if any, about the sub DAG entity the user is trying to access. Example: `is_authorized_dag(method="GET", user=user, access_entity=DagAccessEntity.TASK_LOGS, details=DagDetails(id="my-dag"))` checks whether the user access to read DAG logs from the DAG `my-dag`. Another example: `is_authorized_dag(method="GET", user=user, details=DagDetails(id="my-dag"))` checks whether the user has access to the DAG `my-dag` in general. `access_entity` is not provided here, which means the user is trying to only access information the DAG and not "sub-entities" of the DAG. > Likewise, the docs do not clarify the implicit hierarchy of resources/permissioning in the DagAccessEntity. I hope I answered this question in my previous answer. > Whether the FAB auth manager is slated for deprecation in the near future. Not in the near future, we want to deprecate it at some point but when is unclear now. > Which API-action + resource combinations are possible or not, especially as it relates to DAG sub-entities. (I was only able to understand some of these expected action-resource combinations by digging through the various files under airflow.api_fastapi.core_api.routes.public, but it feels risky to base my assumptions on code which may not be part of the public interface) Can you provide concrete example of what you might think as a combination does not makes sense? It might be simpler to answer that way :) > Should people use the constants in airflow.security.permissions, if not, why / what is that module's intended use? No and it is only there to not break plugins. An attempt was made in the past to remove them and many users complained. > What exactly do [the various id attributes ](https://github.com/apache/airflow/blob/3.0.2/airflow-core/src/airflow/api_fastapi/auth/managers/models/resource_details.py#L44-L65)refer to in the classes defined in airflow.api_fastapi.auth.models.resource_details passed into the auth manager's is_authorized_* methods? How should user's rely on those fields, and what is the recommended approach for when those resource details arguments are None? As I explained previously, these details attributes/classes are there to provide more information about a resource. If the user tries to access a connection, what is the connection ID. If it is a variable, what is the variable ID. When those resource details are None, depending on the method it means: - `GET`. Whether the user has access to see a type of resource in general. It does not mean all of them but some of them. It could be rephrased to: "whether the user is able to list DAGs" (if the resource is DAG, the same applies for the other kind of resources) - `POST`. Whether the user has access to create a given type of resource - `PUT`. Not sure this combination makes sense - `DELETE`. Not sure this combination makes sense - `MENU`. This could be potentially dropped from this list. It needs further investigation but it might not makes sense to keep it as `ResourceMethod` since menu items are filtered by `filter_authorized_menu_items` I hope I answered some of your questions and I really hope you'd be able to make some modifications in space. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
