How to change default swagger.json file path? - nginx

I have created Ngnix-Consul Docker setup referred https://github.com/nginxinc/NGINX-Demos/tree/master/consul-template-demo.
And have created many microservices. So All the microservices are accessible only after adding the service name for e.g.
http://example.com/service_name/get_data
All is working fine then I wanted to add swagger for all microservices so tried with below snippet
I am able to access swagger ui by using
http://example.com/service_name/ui
But the problem is I am not able to load swagger.json in that ui as its trying to access swagger.json on below url
http://example.com/swagger.json
but the json file is on
http://example.com/service_name/swagger.json
How can I change the default path of swagger.json?
The applications in microservices are created in python-flask
I have tried below snippet
swagger: "2.0"
info:
description: "Add service"
version: "1.0.0"
title: "Add Service"
contact:
email: "abc#efg.com"
license:
name: "s1.0"
url: "http://sample.com"
host: "abc.efg.com"
tags:
- name: "add service"
description: "service"
- name: "delete service"
description: "data"
schemes:
- "http"
paths:
/service_name/get_data:
and even I have tried to add basePath in the swagger.yaml file
then It did not even open swaggerui
swagger: "2.0"
info:
description: "Add service"
version: "1.0.0"
title: "Add Service"
contact:
email: "abc#efg.com"
license:
name: "s1.0"
url: "http://sample.com"
host: "abc.efg.com"
basePath: "service_name"
tags:
- name: "add service"
description: "service"
- name: "delete service"
description: "data"
schemes:
- "http"
paths:
/get_data:
Update:
from flask import Flask
import connexion
app = Flask(__name__)
app = connexion.App(__name__)
app.add_api('swagger.yaml')
//apis
if __name__ == "__main__":
app.run(host='0.0.0.0', port=8090, debug=True)

Had similar problem myself. The solution for me was to disable path rewrite in the NGINX level, so that the microservice would receive the full url:
Before:
Request:
http://example.com/service_name/get_data
Service sees:
/get_data
After:
Request:
http://example.com/service_name/get_data
Service sees:
/service_name/get_data
Only then you can specify basePath as "service_name" in the swagger.yaml file:
swagger: "2.0"
info:
description: "Add service"
version: "1.0.0"
title: "Add Service"
host: "abc.efg.com"
basePath: "service_name"

If file swagger.json is static in NGINX config you can make alias rule like this:
location ^~ /swagger.json {
alias /path_to/swagger.json;
}

Related

WSO2 APIM 4.1.0 (Linux) : REST API testing fails in Publisher : Invalid URL., RESOURCE = /xxxx HEALTH CHECK URL = xxxx

I'm trying to create a simple REST API with a mock back-end in the publisher and test it in the publisher itself, before publishing it to the Dev portal.
Swagger definition
openapi: 3.0.1
info:
title: TestAPI
version: '1.0'
servers:
- url: /
security:
- default: []
paths:
/getMessage:
get:
parameters: []
responses:
'200':
description: ok
security:
- default: []
x-auth-type: Application & Application User
x-throttling-tier: Unlimited
x-wso2-application-security:
security-types:
- oauth2
optional: false
components:
securitySchemes:
default:
type: oauth2
flows:
implicit:
authorizationUrl: 'https://test.com'
scopes: {}
x-wso2-auth-header: Authorization
x-wso2-cors:
corsConfigurationEnabled: false
accessControlAllowOrigins:
- '*'
accessControlAllowCredentials: false
accessControlAllowHeaders:
- authorization
- Access-Control-Allow-Origin
- Content-Type
- SOAPAction
- apikey
- Internal-Key
accessControlAllowMethods:
- GET
- PUT
- POST
- DELETE
- PATCH
- OPTIONS
x-wso2-production-endpoints:
urls:
- 'https://run.mocky.io/v3/64df2918-ea8d-4fc9-8e6e-1f57d8b07070'
type: http
x-wso2-sandbox-endpoints:
urls:
- 'https://run.mocky.io/v3/64df2918-ea8d-4fc9-8e6e-1f57d8b07070'
type: http
x-wso2-basePath: /test/1.0
x-wso2-transports:
- http
- https
x-wso2-response-cache:
enabled: false
cacheTimeoutInSeconds: 300
Request (generated from the "Test -> Try it out" section )
curl -X 'GET' \
'https://localhost:8243/test/1.0/getMessage' \
-H 'accept: */*' \
-H 'Internal-Key: [key]'
Response (from postman)
{
"code": "404",
"type": "Status report",
"message": "Not Found",
"description": "The requested resource is not available."
}
APIM Log
[2022-06-07 12:02:06,610] INFO - LogMediator STATUS = Message dispatched to the main sequence. Invalid URL., RESOURCE = /test/1.0/getMessage, HEALTH CHECK URL = /test/1.0/getMessage
NOTE: The sample "PizzaShack" API gets deployed correctly and works fine but when I try to create one from scratch it always gives the Invalid URL error. The request URL seems fine to me, what am I doing wrong ?

Enable CORS for Cloud Run with Cloud Endpoints v1

I have been following an article on Medium to deploy Cloud Endpoints v1 in front of a Cloud Run service hosting a REST API and everything works well.
I now have a requirement to enable CORS support and I've added the below configuration to my endpoints YAML file but get an error saying "This service does not allow CORS traffic" when my browser tries to make a pre-flight request (I've tested this with Postman too with the same error). I know there's a flag to enable CORS --cors_preset=basic using environment variables but I'm not sure what key to set with. Any ideas or help is appreciated.
Endpoints YAML snipper:
swagger: '2.0'
info:
title: Cloud Endpoints with Cloud Run
description: Testing Cloud Endpoints with Cloud Run
version: 1.0.0
host: endpoint-<hash>-uc.a.run.app
x-google-endpoints:
- name: endpoint-<hash>-uc.a.run.app
allowCors: true
schemes:
- https
produces:
- application/json
Error:
{
"code": 7,
"message": "The service does not allow CORS traffic.",
"details": [
{
"#type": "type.googleapis.com/google.rpc.DebugInfo",
"stackEntries": [],
"detail": "service_control"
}
]
}
PS: Thanks Guillaum Blaquiere for the awesome article.
UPDATE:
I ended up testing with an incomplete URL and hence received the above error as my backend service wasn't configured to respond to all pre-flight request URLs. Having fixed this, I now get the below error only on the CORS pre-flight configured URL.
{
"code": 13,
"message": "INTERNAL_SERVER_ERROR",
"details": [
{
"#type": "type.googleapis.com/google.rpc.DebugInfo",
"stackEntries": [
],
"detail": "application"
}
]
}
and logs:
invalid URL prefix in "", client: <CLIENT_IP>, server: , request: "OPTIONS /api/v1/<REMAINING_URL> HTTP/1.1", host: "endpoint-<HASH>-uc.a.run.app"
I would say it's necesary to add ESPv2 Config, I've noticed that the note regarding the ESPv2 config was added since last april, and the Medium document was published on 2019, so I think such required step was not mentioned before.
Later in the same section it's mentioned that the flags for cors are passed by the "--set-env-vars" flag of the deploy command.
You can find more about the ESPv2 Beta startup options in here.
I managed to resolve the issue by defining OPTIONS operations in my YAML file with no security, for each path that I had already defined. See below example YAML file for an endpoint path '/api/v1/hello' with GET and OPTIONS operations defined.
swagger: '2.0'
info:
title: Cloud Endpoints with Cloud Run
description: Testing Cloud Endpoints with Cloud Run
version: 1.0.0
host: endpoint-randomhash-uc.a.run.app
x-google-endpoints:
- name: endpoint-randomhash-uc.a.run.app
allowCors: true
schemes:
- https
produces:
- application/json
x-google-backend:
address: https://backend-randomhash-uc.a.run.app
path_translation: APPEND_PATH_TO_ADDRESS
security:
- auth0_jwk: []
paths:
/api/v1/hello:
get:
summary: Say hello
operationId: helloName
parameters:
- name: "name"
in: "query"
description: "Your name"
type: "string"
responses:
'200':
description: Successful operation
schema:
type: string
options:
summary: CORS pre-flight for say hello
operationId: helloNameOptions
parameters:
- name: "name"
in: "query"
description: "Your name"
type: "string"
responses:
'200':
description: Successful operation
schema:
type: string
security: []
securityDefinitions:
auth0_jwk:
authorizationUrl: ""
flow: "implicit"
type: "oauth2"
x-google-issuer: "https://project.auth0.com/"
x-google-jwks_uri: "https://project.auth0.com/.well-known/jwks.json"
x-google-audiences: "firebase-application-host"
As Sergio pointed out in his comment to a SO question, the other option in my case is to use Firebase Hosting proxy to use the same domain and avoid CORS.

VirtualService routing only uses one host

I have the following VirtualService:
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: external-vs
namespace: dev
spec:
hosts:
- "*"
gateways:
- http-gateway
http:
- name: "postauth"
match:
- uri:
exact: /postauth
route:
- destination:
port:
number: 8080
host: postauth
- name: "frontend"
match:
- uri:
exact: /app
route:
- destination:
port:
number: 8081
host: sa-frontend
I would expect that calls to the /postauth endpoint would be routed to the postauth service and calls to the /app endpoint would be routed to the sa-frontend service. What is happening is that all calls end up being routed to the first router in the file, in the above case to postauth, but if I change the order it will be to sa-frontend
All services and deployments are in the same namespace (dev).
Is that somehow the expected behaviour? My interpretation is that the above should only allow calls to the /postauth and /app endpoints and nothing else, and route these to their respective services.
As per documentaion for Istio 1.3 in HTTPMatchRequest you can find
Field: name, Type: string
I have compared those settings between 1.1 and 1.3 versions:
In version 1.3.4 this paramereter is working properly and the routes were propagated with the names:
[
{
"name": "http.80",
"virtualHosts": [
{
"name": "*:80",
"domains": [
"*",
"*:80"
],
"routes": [
{
"name": "ala1",
"match": {
"prefix": "/hello1",
"caseSensitive": true
},
"route": {
"cluster": "outbound|9020||hello1.default.svc.cluster.local",
.
.
.
{
"name": "ala2",
"match": {
"prefix": "/hello2",
"caseSensitive": true
},
"route": {
"cluster": "outbound|9030||hello2.default.svc.cluster.local",
While in version 1.1 it's not working properly. In those cases please verify your settings with appropriate release.
In addition please refer to Troubleshooting section.
You can verify your applied configuration (changes) inside the cluster, f.e.:
How Envoy instance was configured:
istioctl proxy-config cluster -n istio-system your_istio-ingressgateway-name
Verify routes configuration and virtual hosts for services:
istioctl proxy-config routes -n istio-system your_istio-ingressgateway-name -o json
Hope this help.

There seems to be a mismatch between last deployed API and actually in-use API

According to Google Cloud Console > Endpoints > Services > Deployment History this is the currently deployed API spec:
swagger: "2.0"
info:
title: "JSON Ingester"
description: "Receive JSON files, transform and load them."
version: "1.0.0"
host: "project-id-123.appspot.com"
schemes:
- "https"
paths:
"/upload":
post:
summary: "ETL JSON file."
security:
- api_key: []
operationId: "upload"
consumes:
- multipart/form-data
parameters:
- in: formData
name: file
type: string
responses:
200:
description: "File uploaded."
schema:
type: string
400:
description: "Error during file upload."
securityDefinitions:
api_key:
type: "apiKey"
name: "apikey"
in: "query"
But the key "apikey" is not accepted - instead it requires "key" which was specified in an openapi.yaml that I deployed few hours ago.
This works while it shouldn't:
$ curl -X POST -F "file=#data/file_6.json" https://project-id-123.appspot.com/upload\?key\=AIzaS...Eaoog
And this doesn't work while it should:
$ curl -X POST -F "file=#data/file_6.json" https://project-id-123.appspot.com/upload\?apikey\=AIzaS...Eaoog
{
"code": 16,
"message": "Method doesn't allow unregistered callers (callers without established identity). Please use API Key or other form of API consumer identity to call this API.",
"details": [
{
"#type": "type.googleapis.com/google.rpc.DebugInfo",
"stackEntries": [],
"detail": "service_control"
}
]
}
Do I have to clear a cache or something?
For deploying the API I use:
gcloud endpoints services deploy "./openapi.yaml"
Any ideas?
What rollout_strategy did you use when you deploy ESP? If not specified, default is "fixed". You should use "managed"
Please also check the generated service config by CLI "gcloud endpoints configs describe". Check its system_parameters filed to see if your new "apikey" is created properly.

Connect Doctrine to memcached pool

Perhaps anybody know, how to connect Doctrine to memcached pool, to use it as a cache driver?
I've check official bundle documentation, and lot of another sources, but didn't find any examples of such connection.
Also due to source code, I could not find any options to use pool, but perhaps I miss something.
Didn't test, but the following should work:
in app/config/parameters.yml, set/add
parameters:
memcached.servers:
- { host: 127.0.0.1, port: 11211 }
- { host: 127.0.0.2, port: 11211 }
in app/config/config.yml set/add
services:
memcache:
# class 'Memcache' or 'Memcached', depending on which PHP module you use
class: Memcache
calls:
- [ addServers, [ %memcached.servers% ]]
doctrine.cache.memcached:
class: Doctrine\Common\Cache\MemcachedCache
calls:
- [setMemcached, [#memcached]]
in app/config/config_prod.yml, set
doctrine:
orm:
metadata_cache_driver:
type: service
id: doctrine.cache.memcached
query_cache_driver:
type: service
id: doctrine.cache.memcached
result_cache_driver:
type: service
id: doctrine.cache.memcached
As I said, I can't test it, but this is the combination of several known-to-work techniques.
UPDATE: solution updated based on CrazySquirrel's findings.
Thanks lxg for your ideas. I've build right configuration using your ideas. Please find correct service definition below:
application config:
result_cache_driver:
type: service
id: doctrine.cache.memcached
service.yml
memcached:
class: Memcached
calls:
- [ addServers, [ %memcached_servers% ]]
doctrine.cache.memcached:
class: Doctrine\Common\Cache\MemcachedCache
calls:
- [setMemcached, [#memcached]]

Resources