Replies: 1 comment · 9 replies
-
|
Server urls in the root, path-item object and operation object already exist, but I believe these would only be used for processing the runtime request's URI (e.g. to match a request to the appropriate /paths/* entry in the document), not security URIs. |
Beta Was this translation helpful? Give feedback.
-
|
@karenetheridge This is all my interpretation, btw. That doesn't necessarily mean it's correct. |
Beta Was this translation helpful? Give feedback.
-
|
This could probably use a clarification then. I'm looking through the schema at all the uri-references, and some of them seem intuitively that they'd resolve against the OAD itself with the retrieval uri and $self (e.g. jsonSchemaDialect, /info/termsOfService) and some against an http request at runtime, but I don't think the revisions for 3.2 about URIs differentiates between the two types. |
Beta Was this translation helpful? Give feedback.
-
|
I put up my initial thoughts here - #4926 |
Beta Was this translation helpful? Give feedback.
-
|
@karenetheridge it should be possible to fully determine the behavior of all fields from the definitions given in the sections on resolving API description URIs and API URLs. Anything that is part of interacting with the API (including potentially-3rd-party services like auth servers) is an API URL. Anything that needs to be resolved in order to use the entire OpenAPI Description is an API Description URI and resolved against a base URI per RFC3986 (which is not necessarily the retrieval URI, even if |
Beta Was this translation helpful? Give feedback.
-
|
@karenetheridge I'm not disputing that it may need clarification and there may be some things mis-categorized or unclear, just trying to figure out what isn't covered by the existing definitions. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I have a microservice with endpoints secured using OAuth 2.0. The service runs in three different servers/environments (Local, Dev, and SIT), and each environment uses a different authorization server with its own Auth URL, Access Token URL, etc. Is there a way to define a single security schema that can adjust these URLs automatically based on the selected server/environment?
Beta Was this translation helpful? Give feedback.
All reactions