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: [email protected] Mobile: +91 9730079985 On Fri, Jun 16, 2023 at 10:21 PM Jed Cunningham <[email protected]> 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 <[email protected] > > > 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" <[email protected] > > <mailto:[email protected]>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 :) > > > > > > > > >
