From f91b9a389cb1e4255572c7204a02b8b133862f17 Mon Sep 17 00:00:00 2001 From: Erica Delagnier Date: Wed, 23 Oct 2024 22:57:15 +0200 Subject: [PATCH] auth module documentation suggestion (#1977) After going back and forth because I kept having a "module not found" error, I finally tried to use the complete path. I realized afterward that the doc specified you had to use "explicit" routing but I set up the routing so long ago that it didn't click. I was focused on the "same syntax that is used to connect an operationId". This may not be the best way to clarify it (maybe a Troubleshooting section ?) but I just thought I would make a suggestion. Thanks for your work ! --------- Co-authored-by: Robbe Sneyders --- docs/security.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/security.rst b/docs/security.rst index df45c1007..bf0b84130 100644 --- a/docs/security.rst +++ b/docs/security.rst @@ -29,7 +29,7 @@ validate the incoming credentials, and return information about the authenticate The validation function must either be defined in the API security definition as ``x-{type}InfoFunc``, or in the environment variables as ``{TYPE}INFO_FUNC``. The function should be referenced as a string using the same syntax that is used to connect an ``operationId`` -to a Python function when :ref:`routing `. +to a Python function when :ref:`routing `. Note that even if you used a resolver for the operation id, it is not applied to the validation function, and you need to specify the complete path to the security module While the validation functions should accept different arguments based on the authentication type (as documented below), they should all return a dict which complies with `RFC 7662 `_: