Since there isn't currently a native databricks powerapps connector, I set up a custom connector that calls the jobs runnow api using an AD backed service principle bearer token. I then shared the custom connector and the connection with users for them to run. While this is working fine for everyone on my team, the actual end users are getting a 401 error response. Since everyone on my team are admins in Azure and Databricks, it's likely we have permissions that the end users don't. However, we're having a hard time pinpointing where that might be.
During PowerApps monitoring sessions, we did notice that the Request URL is different for the users getting successful 200 responses, versus those getting 401. The odd thing is, neither matches the specified host in the custom connector. Can anyone tell me how this is generated?
Here is the custom connector code we're using:
swagger: '2.0'
info: {title: Databricks Jobs, description: Call Databricks Jobs API,
version: '1.0'}
host: <databricksInstance>.azuredatabricks.net
basePath: /api/2.1/jobs/
schemes: [https]
consumes: []
produces: []
paths:
/run-now:
post:
responses:
default:
description: default
schema:
type: object
properties:
run_id: {type: integer, format: int32, description: run_id}
number_in_job: {type: integer, format: int32, description: number_in_job}
summary: Start Databricks Notebook as a Job
description: Start Databricks Notebook as a Job
operationId: run-now
x-ms-visibility: important
parameters:
- {name: Content-Type, in: header, required: true, type: string, default: application/json,
x-ms-visibility: internal}
- {name: Accept, in: header, required: true, type: string, default: application/json,
x-ms-visibility: internal}
- name: body
in: body
required: true
schema:
type: object
properties:
job_id: {type: integer, format: int64, description: job_id, title: ''}
required: [job_id]
definitions: {}
parameters: {}
responses: {}
securityDefinitions:
API Key: {type: apiKey, in: header, name: Authorization}
security:
- API Key: []
tags: []
Here is the actual request as seen in PowerApps monitor that returns a successful 200 code (same url for everyone getting a success):
And here is the actual request sent that returns the 401 error:
As you can see, the request url is the same for both except for that last highlighted string. Can anyone tell me how that is generated from the specified host in the API call definition? Any idea what that may signify?
Related
Can I use my own custom formats in my OpenAPI definition and have the AWS API Gateway validate using them? I can't find any reference for this so I assume not?
For example, I would only like to greet guys named Dave:
swagger: "2.0"
info:
version: "1.0"
title: "Hello World API"
paths:
/hello/{user}:
get:
description: Returns a greeting to the user!
parameters:
- name: user
in: path
type: string
required: true
description: The name of the user to greet.
format: "guys-named-dave"
The documentation on this is a bit implicit, indeed. If you combine this
https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-validation-set-up.html
with this
https://swagger.io/specification/#schema-object
the following should be a solution, that works (and it does!)
paths:
/hello
get:
x-amazon-apigateway-request-validator: params
parameters:
- name: user
in: path
required: true
schema:
type: string
pattern: ^.*dave.*$
x-amazon-apigateway-request-validators:
params:
validateRequestParameters: true
To allow for case insensitive names like "Dave" and "DAVE", try the pattern /.*dave.*/i. I don't know if this will work.
I want to upload a list of files using swagger api and I can not find a way in which I get the endpoint generated having a list of MultipartFile. Could you please help me? I also searched in the swagger documentation without any luck. For now I have the following swagger config:
x-swagger-router-controller: attachments
post:
operationId: saveFiles
summary: saves the uploaded files
tags:
- files
consumes:
- multipart/form-data
produces:
- application/json
parameters:
- name: files
in: formData
type: array
items:
type: file
description: Files to be uploaded
required: true
- name: type
type: array
items:
type: string
description: File types
in: path
required: true
responses:
201:
description: Saved files
schema:
$ref: '#/definitions/CreatedFilesResponse'
415:
description: Unsupported media type
schema:
$ref: '#/definitions/ErrorResponse'
default:
description: Error
schema:
$ref: '#/definitions/ErrorResponse'
this code generates the following spring endpoint
public ResponseEntity<CreatedAttachmentsResponse> createFile(List<File> list, List<String> list1) {
return null;
}
Is it possible to validate example part of swagger document against corresponding schema?
I've found tools for both validating schema itself (like http://editor.swagger.io or swagger-cli etc - but that's just linting) and validating requests/responses against schema (things like swagger-express-middleware or swagger-assertions).
But I'd like to validate that examples in responses and definitions are consistent with schemas.
For example:
swagger: '2.0'
paths:
/test:
get:
description: test endpoint
produces:
- application/json
responses:
200:
description: OK
schema:
type: object
properties:
name:
type: string
id:
type: integer
example:
name: 13
id: some string
seems to be "correct" for all those tools even if example contains incorrect structure.
is there a tool that can do that?
I am trying to define my APIs using openapi version 3.0.0. I've generated following YAML file:
openapi: 3.0.0
info:
title: My YAML
description: My YAML
version: 1.0.0
servers:
- url: http://my.server.url
paths:
/v1/service/uri:
post:
summary: Getting some information.
parameters:
- name: Content-Type
in: header
description: Content type of request body.
required: true
style: simple
explode: false
schema:
type: string
- name: Host
in: header
description: Originate host which returns the response.
required: false
style: simple
explode: false
schema:
type: string
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/MyPostRequest'
example:
my_name: "zizi"
my_age: 29
required: true
responses:
200:
description: OK
content:
application/json:
schema:
$ref: '#/components/schemas/MyPostResponse'
components:
schemas:
MyPostRequest:
type: object
properties:
my_name:
type: string
my_age:
type: integer
format: int32
MyPostResponse:
type: object
properties:
status:
type: integer
format: int32
When I copy/paste these lines into Swagger Editor, it gives me duplicated mapping key error on line 19; it is for section description of parameter Content-Type.
I have studied openapi documentation, but I didn't see anything wrong with my YAML file.
I am not sure why you get that error, I tried to find out in which language Swagger is written, as there are several YAML parsers out there that are known to have problems, but couldn't easily determine that using google or wikipedia.
You don't have any duplicate keys in your file, but it is invalid (i.e. not valid YAML) because of the indentation of the key content (the second occurrence, the one under paths →
/v1/service/uri → post → responses → 200), that should be aligned with
description as that key cannot have a value node that is both a scalar (OK) as well as a mapping node content: ....
I want to send a object in a post but with a api key.
How can I describe this in OpenAPI-Specification 2.0?
I tried this (a subset in yaml):
paths:
/eau:
post:
tags:
- Pets
summary: Send a pet
description: 'Send a pet'
operationId: sendapet
consumes:
- application/json
produces:
- application/json
parameters:
- in: body
name: pet
description: Send a pet
required: true
schema:
$ref: '#/definitions/pet'
- in: header
name: api_key
But at
- in: header
name: api_key
I get the following error:
Schema error at paths['/pet'].post.parameters[1].in
should be equal to one of the allowed values
allowedValues: body
Jump to line 36
Schema error at paths['/pet'].post.parameters[1]
should match exactly one schema in oneOf
Jump to line 36
Schema error at paths['/pet'].post.parameters[1]
should NOT have additional properties
additionalProperty: in, name
Jump to line 36
The error occurs because the header parameter is missing type.
However, API keys are related to authentication/authorization, so they should be described using the securityDefinitions and security keywords instead of a header parameter:
securityDefinitions:
apiKey:
type: apiKey
in: header
name: api_key
security:
- apiKey: []
More info: API Keys