On Fri, Feb 28, 2020 at 4:15 PM Ash Berlin-Taylor <a...@apache.org> wrote: > > Great work Kamil, I can't wait till we have a fully featured API in Airflow! > > So AIP-13 has been voted on and "accepted". Do you have a proposal for what > we should do with that AIP that we've already voted upon?
I think we can mark this as abandoned after voting on this AIP In the community, it is natural that some things are abandoned at various levels of development. > In the permissions section you talk about creating, for example > "can_edit_variable" -- but on which view? Permissions in FAB are a on a > specific view -- see > https://github.com/dpgaspar/Flask-AppBuilder/blob/120bc3ca38c4559a0099fe3b1a1badb319b6546e/flask_appbuilder/security/sqla/models.py#L71-L78 I think it won't be a problem to modify this solution and store permission information only in the code for the API. We will not use the permission view table completely. Currently, permissions are checked as follows. 1. Check the authorization data and assign the user to the current request. identification and authentication 2. It is checked to which roles the user is assigned. https://github.com/dpgaspar/Flask-AppBuilder/blob/120bc3ca38c4559a0099fe3b1a1badb319b6546e/flask_appbuilder/security/sqla/models.py#L84-L91 3. The current permissions for the view are checked. https://github.com/dpgaspar/Flask-AppBuilder/blob/120bc3ca38c4559a0099fe3b1a1badb319b6546e/flask_appbuilder/security/sqla/models.py#L71-L81 4. It is checked which permissions have user roles https://github.com/dpgaspar/Flask-AppBuilder/blob/120bc3ca38c4559a0099fe3b1a1badb319b6546e/flask_appbuilder/security/sqla/models.py#L48-L55 5. It is checked that all permissions from 3 are contained in 4. If so, the user is authorized. If not then the user is not authorized to access the view. In the case of API, all we have to do is replace steps 4 and retrieve information from the code, not the database. > "There are not many FAB REST API experts" -- there aren't that many connexion > experts either - has anyone involved with the project used connexion before?. > It's a wildly inaccurate metric, but > https://hugovk.github.io/top-pypi-packages/ lists FAB in position 980 and > connexion in 1146, so they are both about as popular as each other. FAB is a tool with much wider possibilities, so the number of stars does not indicate its popularity in the case of API implementation. Stars indicate its general popularity. > On Feb 26 2020, at 4:40 pm, Kamil Breguła <kamil.breg...@polidea.com> wrote: > > Hello, > > > > I just created "AIP-32 - Airflow REST API" proposal and would love > > community feedback and comments. > > https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-32%3A+Airflow+REST+API > > I would love to know what is your expectation from the API. > > > > We currently have one experimental API, but despite its existence for > > 2 years, it has not reached a stable level. There are many critical > > aspects to this implementation including no defined schema, very > > narrow range of functions, unsafe default configuration, no HATEOAS, > > and many others. > > > > In the past, Drewstone began work on REST API based on OpenAPI. It's > > described by AIP-13: OpenAPI 3 based API definition. However, it was > > not completed due to the lack of interest from the author and the > > Kerberos configuration problem (It was at a time when Breeze was still > > developing, so configuring all dependencies, including Kerberos, was a > > problem). It had a narrow range of features that are expected by users > > e.g. access to XCOM data and management for connection is missing, > > > > The Polidea and Google teams together with the community want to make > > another attempt based on our and community experience. Airflow > > deserves new stable solutions. > > > > Any comments and feedback/discussion in the AIP-32 document are welcome! > > Best regards, > > Kamil Breguła > > >
