Missing security_schemes in components in #[openapi(...)] attribute.

[flo-at]

As the documentation correctly states:

Currently only schema and response components are supported.

in components in the #[openapi(...)] attribute.

The workaround is to first generate the utoipa::openapi::OpenApi object and then use add_security_scheme(...) on the components member.

Is this because security_schemes is more complex to handle in the macro?
The other two options (schemas and responses) are wrapped in a utoipa::openapi::RefOr, so I guess security_schemes being different here is the root of the prolem.

It would be good to have support for security_schemes in the attribute so everything is in one place.

Cheers!

[juhaku]

Is this because security_schemes is more complex to handle in the macro?
The other two options (schemas and responses) are wrapped in a utoipa::openapi::RefOr, so I guess security_schemes being different here is the root of the prolem.

That is the reason. It is more complex in structure and would produce a macro definition that is not necessarily fun to write. Though this could be worked through to streamline it. Moreover security schema might be something that is going to be applied conditionally thus macro attribute would not make sense in such a case. Or it might include some fields that should be defined in some config file and currently OpenApi and other derive macros allow literal strings as arguments. Yet this can be changed to allow references to const values as well and plans are already laid to do so.

Sure support for this could be added in future. PR:s are always welcome. 🙂

[flo-at]

Thank's for the insights! At least the URL is probably sourced from an environment variable or config file so you are right, the macro probably won't be the right place then anyway.

[juhaku]

Yeah, values for macro arguments need to be available during build time which might not be ideal in all cases