The OpenAPI 3.0 docs about apiKey security have left me confused about the use of a field in the 'security' component of the specification. What is the purpose of the array value on the field that points to one of the defined securitySchemes.
Place holder keys? Nothing?
openapi: 3.0.0
...
components:
securitySchemes:
ApiKeyAuth:
type: apiKey
in: header
name: X-API-KEY
security:
- ApiKeyAuth: [] <-- What's the array for?
This array contains a list of required scopes, but the "API key" security scheme does not use scopes. Scopes are only used with OAuth 2.0 and OpenID Connect security schemes. There's an enhancement request to allow scopes for API keys too.
Related
Consider HTML. You write a tag <img src="http://example.com/image.png"/> and the browser retrieves the image at the location specified. I'm designing my API to use a similar mechanism where it's up to the server where any secondary resources and it supplies the location of those resources in the form of a URL.
I'm writing an OpenAPI document to describe all the JSON structures that are sent up to and returned by the server. It works great except I don't know how to express the relationship between the URL inside the response to the first resource to the second resource.
openapi: 3.0.3
info:
title: Minimal Spec for Question.
version: 0.0.0
paths:
/firstRefToSecond:
get:
description: Gets some data including a reference to a secondary resource.
responses:
'200':
description: Successful operation
content:
application/json:
schema:
type: object
properties:
RefToSecond:
type: string
description: The URL to the second resource.
example: "http://example.org/second"
/secondResourceExampleUrlNotActuallyThisUrl:
get:
description:
The second resource.
Found at the URL pointed to by RefToSecond.
responses:
'200':
description: Successful operation
content:
application/json:
schema:
type: object
properties:
Data:
type: integer
description: The data.
example: 12
Here, the second "path" is simply a placeholder for the second URL. I would prefer not to have that placeholder at all and instead substitute the path for wherever that URL points.
Is there a way in OpenAPI to express this relationship between the "refToSecond" URL property and the requirements of what that secondary interaction would look like, without linking it to an explicit URL set in advance?
Is there a way in OpenAPI to express this relationship between the "refToSecond" URL property and the requirements of what that secondary interaction would look like, without linking it to an explicit URL set in advance?
It is possible to formally express a relationship between the response of an operation and another request URL: See the Link feature. The section "Runtime Expression Syntax" is apparently helpful for your case. (Disclaimer: I have never seen this feature being used anywhere in practice so far.)
But this only allows to express the relation to the operation that is available at the server-defined URL. You cannot specify dynamic endpoints in OpenAPI, so you cannot provide a detailed description of the request and response (except in the way you showed in the question).
I'm using the HttpApi (Api Gateway) with a HttpAlbIntegration to connect to my backend. My backend requires a X-API-KEY header with a value comming from a custom claim in the JWT. So my setup is something like this:
const integration = new HttpAlbIntegration(`http-alb-integration`, albListener, {
method: HttpMethod.ANY,
vpcLink: vpcLinkStack.vpcLink,
parameterMapping: new ParameterMapping()
.appendHeader('x-api-key', MappingValue.contextVariable("authorizer.claims['custom:api_key']")
});
According to this https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-enable-cognito-user-pool.html, it should work, but cdk complains about:
Invalid mapping expression specified: Validation Result: warnings : [], errors :
[Invalid mapping expression specified: $context.authorizer.claims['custom:api_key']]
All the other claims work fine: email and sub for instance. The problem only happens with custom attributes, I'm guessing because of the sintax that includes a :. I've tried different sintax alternatives, no luck. The straight question is:
how can I access custom claims from cognito authorizer in HttpApi integration?
I have some schema definitions created with fastify as in below, where I have used 'title' to give meaningful name of my models.
fastify.addSchema({
$id: 'persistence-query-params',
title: "PersistenceQueryParams", // Here
type: 'object',
description: 'Persistence Service GET API URL query specification. Applicable for GET API only.',
properties: {
...........
},
});
However when I am looking at the json generated from the swagger (I am using fastify-swagger: 4.8.4 and fastify: 3.20.1), I am seeing this
def-7: ## Here
title: PersistenceQueryParams
type: object
description: >-
Persistence Service GET API URL query specification. Applicable for GET
API only.
properties:
This is coming up in the OpenAPI 2.0 https://editor.swagger.io/, when loading the json generated out of that schema.
I have tried out adding the name field also:
name: "PersistenceQueryParams",
However no luck.
How can I create meaningful names, instead of def-0, def-1 etc in OpenAPI 2.0?
Thanks,
Pradip
I am consuming an API that uses string like "foo/bar" to identify (discriminate) JSON objects.
A $ref like $ref: '#/components/schemas/foo/bar' gives me errors.
Is this naming supported? I want to use leverage these properties provided by the API in order to use discrimination to pick the most appropriate component schema.
I am using OpenAPI 3.0.1.
No.
OpenAPI 3.0 component names (including schema names) can only contain these characters:
a-z A-Z 0-9 - . _
(Source)
However, there are no restrictions on property names in schemas, so / can be used in property names:
components:
schemas:
MySchema:
type: object
properties:
foo/bar: # <-----
type: string
I have implemented passport-local strategy and passport-bearer strategy.
When user logins with username/password credentials, I generate JSON Web Token which returns to requester. On each request I get access_token from query, decode this token from JWT to object and make bearer authorization implemented in /api/policies. And all auth works fine.
But when I provide this access_token to RESTful route i.e. user I got empty array.
The problem, that Sails accepts access_token as criteria.
Example:
GET /user ## Forbidden
GET /user?access_token=<token> ## Empty array
How can I disable or fix it?
You would probably be better off sending your access token in a header than in the URL. But if what your asking is how to blacklist a certain property from being used as criteria in a blueprint route, it can be done in the following way in your config/routes.js file:
"GET /user": {blueprint: "find", criteria: {blacklist: ["access_token"]}}
This will override the default blacklist, so you may want to include those defaults in your custom array:
"GET /user": {
blueprint: "find",
criteria: {
blacklist: ["access_token", "limit", "skip", "sort", "populate"]
}
}