Our apps running on springBootVersion "2.3.1.RELEASE" . As per the framework requests hit zuul and are the routed to appropriate app backends. Apps backends are actually mule services. For one of the apps which accepts SOAP requests with attachment is having issues. When request is sent which is a POST request we could confirm both payload and attachment data in zuul DEBUG logs (Receiving Consumer request). But When it reaches the app side both payload and attachment data is missing (verified in app logs). Similar REST services with attachment where content type is multipart\formdata works without any issues. It's only with multipart\related content type we're having issues. Payload and attachment data/size looks fine. Any help on dealing multipart\related request ?
zuul config
servlet:
multipart:
max-file-size: 10MB
max-request-size: 10MB
Related
Using Spring Boot, I have tested the method described here to download a csv file by hitting the backend api.
Here the flow is simple: browser <--request/response--> backend api and the response headers (headers.set(HttpHeaders.CONTENT_DISPOSITION, "attachment; filename=" + csvFileName);) set by the backend api are directly interpreted by the browser and so it's straight forward.
But in my actual production environment, I have an API Gateway (ZUUL in my case) between browser and backend api. And I am not sure if the above approach will work when the request/response goes through api-gateway.
Can api-gateway's interpret the response headers and pass the same to the client i.e browser along with the data. Or any additional configuration is required.
Similarly does file uploads going through api-gateway to backend server need any additional consideration.
I have a google cloud api gateway deployed to send requests to a cloud run service.
The cloud run service hosts a laravel docker container image and to authenticate with my authenticated pages, I need to send an Authorization header (Authorization: Bearer my-user-token-here).
When I send the request directly to the cloud run service, I am able to get the response I need with the Authorization header set. But, when I send the request through the api gateway, I always get an unauthenticated message showing the header is missing in the api request to the cloud run. I am not sure of this though.
I can't find any useful documentation on google cloud api gateway to suggest whether cloud run drops the header.
I am also not sure whether the error is from the openapi.yaml. So far I realized I cannot use the v3 of the openapi documentation but rather v2 as api gateway does not support v2. In the v2 of the openapi docs, the securityDefinitions don't support Authorization header Bearer token but instead supports Authorization header basic.
My Openapi yaml
# openapi2-run.yaml
swagger: "2.0"
info:
title: my-api
description: my custom api
version: 1.0.0
schemes:
- https
produces:
- application/json
consumes:
- application/json
x-google-backend:
address: https://some-cloud-run-url
basePath: /api
host: my-api.nw.gateway.dev
x-google-endpoints:
- name: "my-api.nw.gateway.dev"
allowCors: True
paths:
/user:
get:
summary: Requested user details.
operationId: UserDetails
responses:
"200":
description: Return Requested User Details.
schema:
type: string
"default":
description: Unexpected error
The surprising fact is that if I send the request either locally or directly to the cloud run, it works and I get no authentication error, but when I use the api-gateway, then I get the error. So I am guessing it has to do with the header going missing when the request reaches the cloud run, probably because the yaml definition I have here does not have an authorization header.
We have an API gateway instance which sends requests to cloud functions.
If any incoming requests have an Authorization header, the gateway maps the header details into an X-Forwarded-Authorization header in the request to the cloud function.
I assume it's the same for requests to Cloud Run. I don't have any experience with Laravel to know if it has options to look in the forwarded header, though.
Actually you can ignore it by setting the disable_auth in x-google-backend.
The document is not in google gateway, but in google endpoint as follow.
https://cloud.google.com/endpoints/docs/openapi/openapi-extensions
By the document it said:
When configuring your target backend, you may not want to use IAP or IAM to authenticate requests from ESPv2 if either of these conditions apply:
The backend should allow unauthenticated invocations.
The backend requires the original Authorization header from the API client and cannot use X-Forwarded-Authorization (described in the jwt_audience section).
So in your particular case, you just need to modify a single block like this:
x-google-backend:address:
https://some-cloud-run-url
disable_auth: True
And it will work like a charm.
Beware that once you decide to do the authorization yourself, you cannot set the securityDefinitions in the gateway config. The gcp gateway will throw 401 if you do this.
The 429 responses issued by API Gateway (when lowering the max concurrent requests and exceeding it) do not have the CORS headers, so the ajax request in the browser just throws error without any info that could selectively make it trigger a retry.
Any workaround but for retrying any error in the client app / i.e. any work around to have AWS include the CORS headers in the 429 response? CORS is enabled in API gateway, the OPTIONS method is there and responds the headers, and a lambda responds them itself (proxy integration) - all works well but for the 429.
I had a similar issue that was resolved by this answer. You need to create a custom response for 4** and 5** templates. You can do it manually in the AWS console, like so:
Remember to redeploy the API after changing this.
If API Gateway returns 429 you're probably hitting the limit for Lambda's lambda concurrency (or at least that was in my case). The CORS headers are not being sent to the client, since API Gateway blocks the request before hitting your Lambda.
I have a FileUpload Event that should be sent over to a http:outbound upload URL. In order to do this I have to first authenticate login URL and get the response and set the session id for outbound upload URL to execute. In my case, I have an event listener which listens for the application to publish the event of File Upload. Once it is published my listener can pick up and execute the flow. I am trying to see how this can be implemented because File Upload object would need to persisted until the Login response comes back. Thanks!
For this purpose we suggest a Header Enricher pattern. So, you place that "FileUpload Event" object into some header and restore it back to the payload when you get that session id response.
So, you add a Header Enricher before first HTTP Outbound Gateway.
After this gateway you rearange your message to place that header back into a payload and do something with a session id. (Header I guess?). And only after that your have another HTTP Outbound Gateway for uploading your file.
I speack spanihs. Will try english.
I have a WSO2 proxy service for a backend SOAP WebService. It works fine!
The problem starts when i enable Response Caching for the proxy service, 20 seconds caching.
I set ports in TCPMonitor(localhost 8280 and the one for backend service).
I see that when i send different requests to the proxy, it returns same cached response. It return the response cached for the first request into that 20 seconds of life into the cache.
Differents body http for different requests, but same headers and POST URI.
Does ESB do the hash with headers+body or only the headers?
Thansk for your help
Diego
Are you suing cache mediator?
cache mediator caches the response, whenevr it sees same request comes to the system, it sends back the cached response.
Or else did you enable the response caching fro proxy services?