It is never too late :) These views won't change or won't move, they are not part of the views we will move into auth managers. I am not sure you meant that but I wanted to clarify that. And to your second question, the goal is to replace this decorator which checks if a user has permissions to access to this specific DAG/view to a call (which can be wrapped into a decorator as well, leave that to implementation details) to the method `is_authorized` of the auth manager. We now want the auth manager to take these authz decisions through this method. We will still be able to configure permissions for these views as we are today, as a matter of fact, the purpose of FAB provider is to provide a backward compatible experience, so it is safe to say that whatever you can do today, you should be able to do it with the FAB auth manager.
On 2023-06-20, 9:14 AM, "Pankaj Koti" <pankaj.k...@astronomer.io.inva <mailto:pankaj.k...@astronomer.io.inva>LID> wrote: hi, I like the AIP a lot. Sorry for joining the discussion late. I had a question regarding access to UI views in Airflow. I checked the list of resources in Security -> Resources. I see there we have DAGs as resources. However for these DAGs there are views exposed with the help of flask app e.g. the /dags/<dag_id>/graph or the /dags/<dag_id>/code are views in the UI. Currently, we rely on a set of decorators to verify that a user has perms to access the DAG or not. Would we also consider such views as resources in the AIP and be able to configure perms for users for those views as part of the AIP? Regards, Pankaj Koti *Senior Software Engineer, *OSS Engineering Team. Location: Pune, India Timezone: Indian Standard Time (IST) Email: pankaj.k...@astronomer.io <mailto:pankaj.k...@astronomer.io> Mobile: +91 9730079985 On Fri, Jun 16, 2023 at 10:21 PM Jed Cunningham <jedcunning...@apache.org <mailto:jedcunning...@apache.org>> wrote: > Sounds good to me. Hopefully we can make it happen, but we give ourselves > an escape hatch :) > > On Fri, Jun 16, 2023 at 9:45 AM Beck, Vincent <vincb...@amazon.com.inva > <mailto:vincb...@amazon.com.inva>lid > > > wrote: > > > Thanks for the feedback Jed, that's something I confess I had not thought > > about. It is a valid concern. What I can propose as a compromise is to > > leave the "move FAB auth manager to a separate provider" task to the end > of > > the project and mark it as optional. In other words, we can build > > everything as described in the AIP but keep it in core Airflow as opposed > > to a separate provider. All the user management logic would still be > > "packaged" in the auth manager, and then when everything is implemented > and > > done we can decide whether moving this FAB auth manager to a separate > > provider is feasible/a good idea. > > > > What do you think? > > > > On 2023-06-12, 11:18 AM, "Jed Cunningham" <j...@astronomer.io.inva > > <mailto:j...@astronomer.io.inva> > > <mailto:j...@astronomer.io.inva <mailto:j...@astronomer.io.inva>>LID> wrote: > > > > > > > > Overall I'm happy with the proposal. One thing that concerns me though is > > moving the FAB auth manager into a separate provider. That auth manager > > will need to be able to hook into the db migration tooling, and we don't > > expose that to providers or plugins today. So if we do want to move it, > we > > have to account for that as well. > > > > > > I feel the vast majority of the benefit here comes from being able to sub > > in another auth manager, but having the FAB one "not in core" isn't all > > that consequential at the end of the day. It would keep the strict > version > > requirements of FAB in core though - pick your poison I guess :) > > > > > > > > >
