Got following issue using OpenAPI / Swagger with ESP 1.35.0 on Cloud Run:
/go/{ppage}/subitem:
get:
summary: Get a subitem
operationId: ppage
parameters:
- in: path
name: ppage
type: string
required: true
description: Get/Retrieve a subitem
x-google-backend:
address: https://example.com/go
Given an operation config above, path gets translated into https://example.com/go?ppage=m2jobs, where:
{ppage} path parameter becomes query parameter with key ppage in a call to the backend and
/subitem part of the path vanishes in a call to the backend
Is it correct/expected?
Please advise.
Indeed, according with the following link, the backend proto translates the path parameter to query parameter and the /path/ vanishes after the first /{path param}/
https://github.com/googleapis/googleapis/blob/master/google/api/backend.proto#L35-L91
Your assumptions are correct!
Best
Related
there is a url like
http://someservice.com/confirm?{token}
Is this any way how to describe this endpoint in terms of swagger notation
if use as query parameter then you get
/confirm:
get:
summary: ...
parameters:
- in: query
name: token
...
http://someservice.com/confirm?token=value that is not OK
from other side it is not possible to use url notation in follow way:
/confirm?{token}:
get:
summary: ...
parameters:
- in: path
name: token
...
due to query strings in paths are not allowed.
This is currently not supported, neither in OpenAPI 2.0 nor in OpenAPI 3.0. Here's the corresponding feature request:
Support for arbitrary query strings
I have an API which allows any arbitrary path to be passed in, for example all of these:
/api/tags
/api/tags/foo
/api/tags/foo/bar/baz
Are valid paths. I tried to describe it as follows:
/tags{tag_path}:
get:
parameters:
- name: tag_path
in: path
required: true
type: string
default: "/"
However, https://generator.swagger.io encodes slashes in the path, so it doesn't work. So is there a way to describe my API in Swagger?
This is not supported as of OpenAPI 3.1, and I have to resort to a workaround.
If I have a path /tags{tag_path} and I enter something like this as tag_path: /foo/bar, then the actual query request URL will be: /tags%2Ffoo%2Fbar. So, I just added support for that on my backend: the endpoint handler for /tags* urldecodes the path (which is %2Ffoo%2Fbar), and it becomes /foo/bar again.
Yes, a hack, but it works, and it's better than nothing. In my case, tag names can't contain the / character, so there's no conflict. Your mileage may vary, of course.
If you are using a framework like Connexion, chances are it does support a wildcard path parameter (even though it is not in the OpenAPI spec).
Here is an example for Connexion.
paths:
/pages/{path}:
get:
# (...)
parameters:
- name: "path"
in: path
description: "Remainder of path, including slashes."
schema:
type: string
format: path
The difference is the format: path added.
I have an API defined using Swagger, which defines the following API Key authorizer:
securityDefinitions:
api_key:
type: apiKey
name: x-api-key
in: header
x-amazon-apigateway-authtype: "oauth2"
x-amazon-apigateway-authorizer:
type: token
authorizerUri: arn:aws:apigateway:eu-west-1:lambda:path/2015-03-31/functions/arn:aws:lambda:eu-west-1:[accountid]:function:ApiKeyAuthorizerLambdaFunction/invocations
authorizerResultTtlInSeconds: 0
However, when I pass this Swagger definition into my CloudFormation script and call an endpoint secured with this authorizer, I get a 500. The API Gateway logs show the following:
Incoming identity: ***key
Execution failed due to configuration error: Invalid permissions on Lambda function
Execution failed due to configuration error: Authorizer error
Note that I have given API Gateway permission to execute this lambda:
LambdaPermissionAuthorizerApiGateway:
Type: AWS::Lambda::Permission
Properties:
FunctionName:
Fn::GetAtt:
- ApiKeyAuthorizerLambdaFunction
- Arn
Action: lambda:InvokeFunction
Principal: apigateway.amazonaws.com
In fact, when I compare the CloudFormation script which Serverless generates for authoized endpoints (using Serverless's notation) with my own CloudFormation script using Swagger, I see little difference between them, except that my authorizer is defined with Swagger rather than directly as a CF resource.
Can anyone shed any light on this? Is this a bug when using Swagger with CloudFormation?
Can you try setting the authorizerCredentials parameter of your x-amazon-apigateway-authorizer to a valid IAM role that has permission to execute the authorizer lambda? Not sure the standard AWS::Lambda::Permission applies for this, though you probably want to keep it for now just in case it is still required.
The x-amazon-apigateway-authorizer docs show an example.
I have an API which allows any arbitrary path to be passed in, for example all of these:
/api/tags
/api/tags/foo
/api/tags/foo/bar/baz
Are valid paths. I tried to describe it as follows:
/tags{tag_path}:
get:
parameters:
- name: tag_path
in: path
required: true
type: string
default: "/"
However, https://generator.swagger.io encodes slashes in the path, so it doesn't work. So is there a way to describe my API in Swagger?
This is not supported as of OpenAPI 3.1, and I have to resort to a workaround.
If I have a path /tags{tag_path} and I enter something like this as tag_path: /foo/bar, then the actual query request URL will be: /tags%2Ffoo%2Fbar. So, I just added support for that on my backend: the endpoint handler for /tags* urldecodes the path (which is %2Ffoo%2Fbar), and it becomes /foo/bar again.
Yes, a hack, but it works, and it's better than nothing. In my case, tag names can't contain the / character, so there's no conflict. Your mileage may vary, of course.
If you are using a framework like Connexion, chances are it does support a wildcard path parameter (even though it is not in the OpenAPI spec).
Here is an example for Connexion.
paths:
/pages/{path}:
get:
# (...)
parameters:
- name: "path"
in: path
description: "Remainder of path, including slashes."
schema:
type: string
format: path
The difference is the format: path added.
I am using swagger-ui to create and test my apis calls but in case where I have a GET call with Authorization header it fails and returns ERROR. When I try to debug I found out that it sends this GET call as OPTIONS if Authorization header is present, else as a GET call.
The strange part is with Authorization header the POST call works fine.
/urlCode:
get:
description: Initiate something
parameters:
- name: Authorization
in: header
description: Authorization token
required: true
type: string
- name: var
in: query
description: variable
required: true
type: string
format: string
This is a CORS issue. To see what's allowed, web applications must first send an OPTIONS request prior to submitting the actual request (which is why you see OPTIONS and not GET). In order for it to work properly, you must enable CORS on the API itself. Further details can be found in swagger-ui's repository.