Allow specifying access control handlers via OAS factory and middleware about falcon-oas HOT 8 CLOSED

Yes, but SomeResource(...) is lambda: SomeResource(...) since it is instantiated in the factory.

I agree to add helpers to avoid extensions.IMPLEMENTATION. I'd like to use OpenAPI terms. For example:

resolve_security_scheme(spec_dict, 'api_key', api_key_validator)
resolve_path_item(spec_dict, '/some/path', lambda: SomeResource(...))

from falcon-oas.

Yes, but SomeResource(...) is lambda: SomeResource(...) since it is instantiated in the factory.

Good point. In fact, this can be hidden in resolve_path_item:

def resolve_path_item(spec_dict, path, resource):
    spec_dict['paths'][path][extensions.IMPLEMENTATION] = lambda: resource

resolve_path_item(spec_dict, '/some/path', SomeResource(...))

I think it's a bit more intuitive without the explicit lambda.

from falcon-oas.

Either is fine.
If 2, I'd like to avoid mutating the given spec_dict and mutate Spec.data directly or by Spec.__getitem__.
I don't worry about the one-liner since I actually use multiple middlewares:

oas = OAS(spec_dict, ...)
app = oas.create_api(middleware=[..., oas.middleware, ...])

from falcon-oas.

How about mutating spec_dict to add x-falcon-oas-implementation key and the handler value before passing it to the factory? In this case it is necessary to add the guard clause (maybe if not isinstance(name, six.string_types): return name) to import_string function but this approach is simple and also applicable to the request handlers.

from falcon-oas.

Do you mean something like this?

from falcon_oas import extensions

def api_key_validator(value, scopes, request):
    # ...

spec_dict = load_spec(...)
spec_dict['components']['securitySchemes']['api_key'][extensions.IMPLEMENTATION] = api_key_validator
spec_dict['paths']['/some/path'][extensions.IMPLEMENTATION] = SomeResource(...)

api = OAS(spec_dict).create_api()

# ...

As you said, then import_string would return name as is when it is not a string.

from falcon-oas.

How about adding helpers to make it a bit more convenient?

set_security(spec_dict, 'api_key', api_key_validator)
set_resource(spec_dict, '/some/path', SomeResource())

from falcon-oas.

I like it! I'll close #26 in favor of a new PR, that implements your suggestion, later today.

from falcon-oas.

One more thing: Which option would you prefer?

1. Make the two helpers independent functions that modify the spec_dict explicitly (as discussed above).
2. Make the two helpers instance methods of the OAS class to hide the implementation detail that spec_dict (or rather self.spec then) is mutated.

   oas = OAS(spec_dict)
   oas.resolve_security_scheme('api_key', api_key_validator)
   oas.resolve_path_item('/some/path', SomeResource(...))
   api = oas.create_api()

   If you're concerned about losing the one-liner api = OAS(spec_dict).create_api(), the two methods could return self allowing:

   api = OAS(spec_dict)
       .resolve_security_scheme('api_key', api_key_validator)
       .resolve_path_item('/some/path', SomeResource(...))
       .create_api()

I tend to prefer 2. because it feels more like a real feature to me rather than an officially supported "trick".

from falcon-oas.