I have a Swagger 2.0 file that has an auth mechanism defined but am getting errors that tell me that we aren't using it. The exact error message is “Security scheme was defined but never used”.
How do I make sure my endpoints are protected using the authentication I created? I have tried a bunch of different things but nothing seems to work.
I am not sure if the actual security scheme is defined, I think it is because we are using it in production.
I would really love to have some help with this as I am worried that our competitor might use this to their advantage and steal some of our data.
swagger: "2.0"
# basic info is basic
info:
version: 1.0.0
title: Das ERP
# host config info
# Added by API Auto Mocking Plugin
host: virtserver.swaggerhub.com
basePath: /rossja/whatchamacallit/1.0.0
#host: whatchamacallit.lebonboncroissant.com
#basePath: /v1
# always be schemin'
schemes:
- https
# we believe in security!
securityDefinitions:
api_key:
type: apiKey
name: api_key
in: header
description: API Key
# a maze of twisty passages all alike
paths:
/dt/invoicestatuses:
get:
tags:
- invoice
summary: Returns a list of invoice statuses
produces:
- application/json
operationId: listInvoiceStatuses
responses:
200:
description: OK
schema:
type: object
properties:
code:
type: integer
value:
type: string
securityDefinitions alone is not enough, this section defines available security schemes but does not apply them.
To actually apply a security scheme to your API, you need to add security requirements on the root level or to individual operations.
security:
- api_key: []
See the API Keys guide for details.
Related
I deployed 2 versions of openapi.yaml file to Google Cloud Endpoint using the Cloud Endpoint's versioning feature(i.e gcloud endpoints services deploy openapi_v1.yaml openapi_v2.yaml). Each version of the yaml file contains a version number and basepath different from the other, one endpoint that use api-key authentication, and definition for api-key authentication tag. After deployed to Endpoint, the configuration shows both yaml file, however deploying an api to Cloud Run ESPv2 using this configuration will only have api-key authentication turned on for the newer version.
Does anyone know if this is a known bug, or there is something else I need to do to enable authentication for all versions?
The .yaml file looks like the following. The two versions I used to test on are identical except version and bathpath:
swagger: "2.0"
info:
description: "This API is used to connect 3rd-party ids to a common user identity"
version: "1.0"
title: "****"
host: "uie-dot-user-id-exchange.appspot.com"
basePath: "/v1"
...
- "https"
x-google-allow: all
paths:
...
/ids/search:
get:
operationId: "id_search"
produces:
- "application/json"
security:
- api_key: []
tags:
- "Ids"
summary: "Privileged endpoint. Provide any id (3rd party or otherwise) and get a hash of all ids associated with it."
parameters:
- in: "query"
name: "id_type"
description: "Type of id to search"
required: true
type: string
- in: "query"
name: "id_value"
description: "Value of id to search"
required: true
type: string
responses:
200:
description: "AssociatedIdsHash"
schema:
$ref: '#/definitions/AssociatedIdsHash'
400:
description: "Bad request. Requires both id_type and id_value query parameters."
401:
description: "Unauthorized. Please provide a valid api-key in the \"api-key\" header."
404:
description: "Not found - no entry found for key provided"
...
################ SECURITY DEFINITIONS ################
securityDefinitions:
# This section configures basic authentication with an API key.
api_key:
type: "apiKey"
name: "key"
in: "query"
I tried to make the api-key work in v1 and v2 but it only works in version 2.
I followed the following link from swagger documentation to create swagger json for my rest api.
https://swagger.io/docs/specification/2-0/describing-request-body/
In my rest api, I have request body and http headers like Content-Type and Authorization that go along with the service request.
I was wondering if there is a way to include request body and http header information in the swagger json ? I don't see that information in the swagger docs.
The Content-Type header of requests and responses is defined by the consumes and produces keywords, respectively. They can be specified on the operation level or on the root level of the spec.
The Authorization header is defined using the securityDefinitions and security keywords. OpenAPI/Swagger 2.0 supports Basic authentication, API keys and OAuth 2.
Other headers can be defined as in: header parameters.
For example, if an operation POSTs JSON and uses Basic auth, you can describe it as follows:
swagger: '2.0'
...
securityDefinitions: # Authorization, part 1
basicAuth:
type: basic
paths:
/something:
post:
summary: POST some JSON
consumes:
- application/json # Request Content-Type
produces:
- application/json # Response Content-Type
security:
- basicAuth: [] # Authorization, part 2
parameters:
- in: body
name: body
required: true
schema:
$ref: '#/definitions/Something'
responses:
200:
description: OK
Relevant documentation:
MIME Types
Authentication
Describing Parameters
I'd like that the root path of my API redirect (301) to completely another site with docs. So I have a lambda at e.g /function1 path and the / should return code 301 with another location. And I'd like to do it without another lambda.
This is exactly what is described here, but via aws command line tool. I tried this approach - it works perfectly, but I'd like to configure such API gateway mock via serverless framework config.
Fortunately, the series of CLI commands you linked to can be reproduced in CloudFormation, which can then be dropped into the Resources section of your Serverless template.
In this example, a GET to /function1 will invoke a lambda function, while a GET to / will return a 301 to a well-known search engine.
service: sls-301-mock
provider:
name: aws
runtime: nodejs12.x
stage: dev
region: us-east-1
functions:
hello:
handler: handler.hello
events:
- http:
path: function1
method: get
resources:
Resources:
Method:
Type: AWS::ApiGateway::Method
Properties:
HttpMethod: GET
ResourceId:
!GetAtt ApiGatewayRestApi.RootResourceId
RestApiId:
Ref: ApiGatewayRestApi
AuthorizationType: NONE
MethodResponses:
- ResponseModels: {"application/json":"Empty"}
StatusCode: 301
ResponseParameters:
"method.response.header.Location": true
Integration:
Type: MOCK
RequestTemplates:
"application/json": "{\n \"statusCode\": 301\n}"
IntegrationResponses:
- StatusCode: 301
ResponseParameters:
"method.response.header.Location": "'https://google.com'"
Tested with:
Framework Core: 1.62.0
Plugin: 3.3.0
SDK: 2.3.0
Components Core: 1.1.2
Components CLI: 1.4.0
Notes
ApiGatewayRestApi is, by convention, the logical name of the API Gateway Stage resource created by Serverless on account of the http event.
Relevant CloudFormation documentation
ApiGateway::Method
ApiGateway::Method Integration
EDIT
This answer is not as verbose, and uses an http event instead of the Resources section. I haven't tested it, but it may also work for you.
Managed to achieve it with referring one function twice. But see also reply of Mike Patrick - looks more universal
...
events:
- http:
path: main/root/to/the/function
method: get
cors: true
- http:
path: /
method: get
integration: mock
request:
template:
application/json: '{"statusCode": 301}'
response:
template: redirect
headers:
Location: "'my-redirect-url-note-the-quotes-they-are-important'"
statusCodes:
301:
pattern: ''
I am stuck with this error while trying to create a channel using api (I am using a similar sample to balance transfer example from fabric samples)
However,I can create a channel,install,instantiate and invoke using the cli commands
I have enclosed both the screenshot of the error and my network-config fileenter image description here
--networkconfig.yaml--
#
The network connection profile provides client applications the information about the target
blockchain network that are necessary for the applications to interact with it. These are all
knowledge that must be acquired from out-of-band sources. This file provides such a source.
name: "business-connect"
#
Any properties with an "x-" prefix will be treated as application-specific, exactly like how naming
in HTTP headers or swagger properties work. The SDK will simply ignore these fields and leave
them for the applications to process. This is a mechanism for different components of an application
to exchange information that are not part of the standard schema described below. In particular,
the "x-type" property with the "hlfv1" value example below is used by Hyperledger Composer to
determine the type of Fabric networks (v0.6 vs. v1.0) it needs to work with.
x-type: "hlfv1"
#
Describe what the target network is/does.
description: "Business connect-POC"
#
Schema version of the content. Used by the SDK to apply the corresponding parsing rules.
version: "1.0"
#
The client section will be added on a per org basis see org1.yaml and org2.yaml
#
client:
#
[Optional]. But most apps would have this section so that channel objects can be constructed
based on the content below. If an app is creating channels, then it likely will not need this
section.
channels: # name of the channel internal-channel:
# Required. list of orderers designated by the application to use for transactions on this
# channel. This list can be a result of access control ("org1" can only access "ordererA"), or
# operational decisions to share loads from applications among the orderers. The values must
# be "names" of orgs defined under "organizations/peers"
orderers:
- orderer1-htc
# Required. list of peers from participating orgs
peers:
peer1-accounts:
# [Optional]. will this peer be sent transaction proposals for endorsement? The peer must
# have the chaincode installed. The app can also use this property to decide which peers
# to send the chaincode install request. Default: true
endorsingPeer: true
# [Optional]. will this peer be sent query proposals? The peer must have the chaincode
# installed. The app can also use this property to decide which peers to send the
# chaincode install request. Default: true
chaincodeQuery: true
# [Optional]. will this peer be sent query proposals that do not require chaincodes, like
# queryBlock(), queryTransaction(), etc. Default: true
ledgerQuery: true
# [Optional]. will this peer be the target of the SDK's listener registration? All peers can
# produce events but the app typically only needs to connect to one to listen to events.
# Default: true
eventSource: true
peer1-mgmt:
endorsingPeer: false
chaincodeQuery: true
ledgerQuery: true
eventSource: false
peer1-project:
endorsingPeer: false
chaincodeQuery: true
ledgerQuery: true
eventSource: true
# [Optional]. what chaincodes are expected to exist on this channel? The application can use
# this information to validate that the target peers are in the expected state by comparing
# this list with the query results of getInstalledChaincodes() and getInstantiatedChaincodes()
chaincodes:
# the format follows the "cannonical name" of chaincodes by fabric code
- mycontract-v0.1
#
list of participating organizations in this network
organizations: htc:
mspid: htcMSP
orderer:
- orderer1-htc
certificateAuthorities:
- ica-htc accounts:
mspid: accountsMSP
peers:
- peer1-accounts
# [Optional]. Certificate Authorities issue certificates for identification purposes in a Fabric based
# network. Typically certificates provisioning is done in a separate process outside of the
# runtime network. Fabric-CA is a special certificate authority that provides a REST APIs for
# dynamic certificate management (enroll, revoke, re-enroll). The following section is only for
# Fabric-CA servers.
certificateAuthorities:
- ica-accounts
# [Optional]. If the application is going to make requests that are reserved to organization
# administrators, including creating/updating channels, installing/instantiating chaincodes, it
# must have access to the admin identity represented by the private key and signing certificate.
# Both properties can be the PEM string or local path to the PEM file. Note that this is mainly for
# convenience in development mode, production systems should not expose sensitive information
# this way. The SDK should allow applications to set the org admin identity via APIs, and only use
# this route as an alternative when it exists.
adminPrivateKey:
path: network/data/orgs/accounts/admin/msp/keystore/accounts_sk
signedCert:
path: network/data/orgs/accounts/admin/msp/signcerts/cert.pem
# the profile will contain public information about organizations
other than the one it belongs to. # These are necessary information
to make transaction lifecycles work, including MSP IDs and # peers
with a public URL to send transaction proposals. The file will not
contain private # information reserved for members of the
organization, such as admin key and certificate, # fabric-ca
registrar enroll ID and secret, etc. mgmt:
mspid: mgmtMSP
peers:
- peer1-mgmt
certificateAuthorities:
- ica-mgmt
adminPrivateKey:
path: network/data/orgs/mgmt/admin/msp/keystore/mgmt_sk
signedCert:
path: network/data/orgs/mgmt/admin/msp/signcerts/cert.pem project:
mspid: projectMSP
peers:
- peer1-project
certificateAuthorities:
- ica-project
adminPrivateKey:
path: network/data/orgs/project/admin/msp/keystore/project_sk
signedCert:
path: network/data/orgs/project/admin/msp/signcerts/cert.pem
#
List of orderers to send transaction and channel create/update requests to. For the time
being only one orderer is needed. If more than one is defined, which one get used by the
SDK is implementation specific. Consult each SDK's documentation for its handling of orderers.
orderers: orderer1-htc:
url: grpcs://localhost:7050
# these are standard properties defined by the gRPC library
# they will be passed in as-is to gRPC client constructor
grpcOptions:
ssl-target-name-override: orderer1-htc
tlsCACerts:
path: network/data/htc.crt
#
List of peers to send various requests to, including endorsement, query
and event listener registration.
peers: peer1-accounts:
# this URL is used to send endorsement and query requests
url: grpcs://localhost:7051
grpcOptions:
ssl-target-name-override: peer1-accounts
tlsCACerts:
path: network/data/accounts.crt
peer1-mgmt:
url: grpcs://localhost:8051
grpcOptions:
ssl-target-name-override: peer1-mgmt
tlsCACerts:
path: network/data/mgmt.crt
peer1-project:
url: grpcs://localhost:9051
grpcOptions:
ssl-target-name-override: peer1-project
tlsCACerts:
path: network/data/project.crt
#
Fabric-CA is a special kind of Certificate Authority provided by Hyperledger Fabric which allows
certificate management to be done via REST APIs. Application may choose to use a standard
Certificate Authority instead of Fabric-CA, in which case this section would not be specified.
certificateAuthorities: ica-htc:
url: http://localhost:1054
httpOptions:
verify: false
tlsCACerts:
path: network/data/htc-ca-cert.pem
registrar:
- enrollId: ica-htc-admin
enrollSecret: ica-htc-adminpw
# [Optional] The optional name of the CA.
caName: ica-htc ica-accounts:
url: http://localhost:7054
# the properties specified under this object are passed to the 'http' client verbatim when
# making the request to the Fabric-CA server
httpOptions:
verify: false
tlsCACerts:
path: network/data/accounts-ca-chain.pem
# Fabric-CA supports dynamic user enrollment via REST APIs. A "root" user, a.k.a registrar, is
# needed to enroll and invoke new users.
registrar:
- enrollId: ica-accounts-admin
enrollSecret: ica-accounts-adminpw
# [Optional] The optional name of the CA.
caName: ica-accounts
ica-mgmt:
url: http://localhost:8054
httpOptions:
verify: false
tlsCACerts:
path: network/data/mgmt-ca-chain.pem
registrar:
- enrollId: ica-mgmt-admin
enrollSecret: ica-mgmt-adminpw
# [Optional] The optional name of the CA.
caName: ica-mgmt
ica-project:
url: http://localhost:9054
httpOptions:
verify: false
tlsCACerts:
path: network/data/project-ca-chain.pem
registrar:
- enrollId: ica-project-admin
enrollSecret: ica-project-adminpw
# [Optional] The optional name of the CA.
caName: ica-project
Looks like you are getting a hostname verification error on the TLS handshake. In your settings
# this URL is used to send endorsement and query requests
url: grpcs://localhost:7051
grpcOptions:
ssl-target-name-override: peer1-accounts
tlsCACerts:
path: network/data/accounts.crt
you are calling localhost but you set the override to peer1-accounts. The hostname you use in the URL must match one of the SANs in the TLS certificate used by the peer OR whatever value you set for ssl-target-name-override must match one of the SANs in the TLS certificate.
You can print the details of the certificate using openssl:
openssl x509 -noout -text -in path-to-tls-cert
This problem is related to blocks in the Firewall. When I disabled SSL checking on my firewall, it worked again, no problem
Context
I am attempting to separate configuration information for our applications using the pattern-matching feature in Spring Cloud Config Server. I have created a repo for "production" environment with a property file floof.yaml. I have created a repo for "development" environment with a property file floof-dev.yaml.
My server config:
spring:
application:
name: "bluemoon"
cloud:
config:
server:
git:
uri: file://${user.home}/tmp/prod
repos:
development:
pattern:
- \*/dev
uri: file://${user.home}/tmp/dev
After starting the server instance, I can successfully retrieve the config content using curl, and can verify which content was served by referring to the "source" element as well as the values for the properties themselves.
Expected Behavior
When I fetch http://localhost:8080/floof/prod I expect to see the source "$HOME/tmp/prod/floof.yaml" and the values from that source, and the actual results match that expectation.
When I fetch http://localhost:8080/floof/dev I expect to see the source "$HOME/tmp/dev/floof-dev.yaml" and the values from that source, but the actual result is the "production" file and contents (the same as if I had fetched .../floof/prod instead.
My Questions
Is my expectation of behavior incorrect? I assume not since there is an example in the documentation in the "Git backend" section that suggests separation by profile is a thing.
Is my server config incorrectly specifying the "development" repo? I turned up the logging verbosity in the server instance and saw nothing in there that called attention to itself in terms of misconfiguration.
Are the property files subject to a naming convention that I'm not following?
I had the same issue. Here is how I resolved::
spring cloud config pattern match for profile
Also, check if you are using Brixton.M5 version.
After some debugging on the PatternMatching source code here is how I resolved the issue: You can choose one of the two ways.
application.yml
server:
port: 8888
spring:
cloud:
config:
server:
git:
uri: ssh://xxxx#github/sample/cloud-config-properties.git
repos:
development:
pattern: '*/development' ## give in quotes
uri: ssh://git#xxxgithub.com/development.git
OR
development:
pattern: xx*/development,*/development ##since it is not allowed to have a value starting with a wildcard( '*' )after pattern I first gave a generic matching but the second value is */development. Since pattern takes multiple values, the second pattern will match with the profile.
uri: ssh://git#xxxgithub.com/development.git
pattern: */development.Error on yml file- expected alphabetic or numeric character, but found but found /.
The reason the profile pattern git repo was not identified because : although spring allows multiple array values for pattern beginning with a '-' in the yml file, the pattern matcher was taking the '-' as string to be matched. i.e it is looking for a pattern '-*/development' instead of '*/development'.
repos:
development:
pattern:
-*/development
-*/staging
Another issue i observed was, I was getting a compilation error on yml file if i had to mention the pattern array as '- */development' - note space after hyphen(which is meant to show that it can hold multiple values as array) and start with a '*/development' with an error: expected alphabetic or numeric character, but found but found /
repos:
development:
pattern:
- */development
- */staging