Advanced authorization per resource

[asfaltboy]

I really like how the "automatic" mode settings is set up and would love to see authorization implemented in the same manner.

For example:

users = {
    'public': {
        'base_query': {
            {'public': True}
        },
        'resource_methods': ['GET'],
        'item_methods': ['GET'],
    },
    'private': {
        'base_query': {
            {
                '_id': 'auth.user.id',
            }
        },
        'item_methods': ['PATCH'],
    },
    'schema': {
        'username': {
            'type': 'string',
        },
        'emails': {
            'type': 'list',
        },
        'public': {
            'type': 'boolean',
        },
        'followers': {
            'type': 'list'
            'actions': ['insert']
        }
    }
}

Basically I'd add 2 security areas (private/public) where one requires authentication and the other doesn't.

Each area could define a "base" query which will be concatenated with the rest of the queries before execution, thus making sure the user can access only the permitted resources.

Furthermore I'd let the user modify which methods are allowed per resource, thus forcing an authorization flow for each request:

1. Check if public permissions exist for request method (i.e GET /users), and if so, serve the request.
2. If not (i.e the PATCH /users example above) test if private permissions for the requested method exist, returning 405 if not.
3. If user if authenticated, serve private permissions while using the base query for private area (in a similar fashion to the public area above)

Notice the use of auth.user.id, this of course takes for granted our ability to expose the currently authenticated user (which is a story of it's own)...

[nicolaiarocci]

Thanks for your contribution. Did you check the latest development changelog? I think most of your ideas are already there in one form or another:

1. Predefined db filters are essentially base queries. Plus, you can have multiple resources (API endpoints) targeting the same database collection
2. You can have have public and private resources, and/or restricted/public methods
3. According to REST principles a REST API is stateless so there's no auth.user.id concept that we can apply here (think no session variables). Each request will have to provide its own Authorization token.
4. Current Auth implementation allows custom authorization logic by means of subclassing (v0.0.4) and, I'm probably going to add standard behavior (check the auth token against a configurable db collection containing username and hashed/salted passwords).

[nicolaiarocci]

838ca5f adds customizable role-based access control, which will allow for implementation of auth.user.id-like scenarios. The idea originated while brainstorming about your proposal so thank you!

[nicolaiarocci]

PS: look at the examples/security folder for some code snippets.

[asfaltboy]

Wow thanks for that! Roles is really a good idea and seems better suited for REST (no need add custom logic per view)