I have a beanstalk reflected in my API gateway with passthrough, where my client sends a direct multipart/form-data request to beanstalk. The image sends correctly and I can open it normally, but when I make the request from the API Gateway, I can't open the image. Looks like the API Gateway encode messes up the image content when performing the passthrough to beanstalk.
How I can set the Api Gateway encode or make a pure passthrough?
Related
I create an API where I configure the endpoint: https://ssl.croinform.ru:450/api.test
And there is a problem with https, I am not getting a response to the request. It seems the WSO2 API Manager API gateway is not proxying requests to the endpoint.
When I make requests directly, I pre-configure the infrastructure: install the openssl counterpart, install the cacer.p7b and ssl.croinform.cer certificates. After that, I successfully receive responses from the ssl.croinform.ru:450/api.test service.
Can you tell me what I need to do to make this work in WSO2 API Manager?
TL;DR: How to authenticate against NGINX if auth headers are not supported on client side?
I am building an IoT-related project using NGINX as a reverse proxy for the server side services and 1NCE as the LTE carrier for the mobile devices. All traffic is authenticated based on HTTPBasicAuth over SSL-encrypted connections and handling "normal" requests works as desired.
As mobile service might be interrupted and the Internet connection might be lost, I want to send SMS for critical status reports and alarm notifications. 1NCE supports SMS mobile originated SMS (MO SMS) which are handled by the 1NCE's internal infrastructure and forwarded to a configurable API endpoint. So, MO SMS are not delivered to a specified phone, but forwarded via an API request which I need to process on my side.
According to 1NCE's SMS documentation and in consultation with their customer support, SMS forwarding does not support any authentication headers. SMS forwarding can only be done by specifying an HTTPS URL (including the desired API endpoint) and a port. The incoming SMS is then wrapped in a request to the given URL and sent in the request body.
I want to add authentication to the SMS forwarding endpoint (receiving forwarded SMS on my side) as well and am currently wondering about how I could achieve this. NGINX supports authentication on subrequest which could be used to evaluate incoming requests by an internal service. So my first idea was to add some credentials to each SMS (as I am also responsible for the SMS sending part of the code on the mobile devices, I could implement whatever is needed) and check those credentials with an internal service called by NGINX's subrequest. However, this does not seem to be doable. According to this SO question GET requests are used for the internal subrequests hence any body of the incoming POST request is discarded. Therefore, the credentials of the forwarded SMS would also be not available to my internal auth service. Extending NGINX's auth capabilities by writing an custom Lua-based plugin was my second idea, but this does not only seem to be not feasible but is also not supported by the NGINX instance I am using (Lua modules are disabled, switching to openresty seems to be a big thing).
My last idea would be to forward all incoming requests to a Python web service (written in Flask, other services I am using are also written in Flask) and parsing the forwarded SMS in Python. Based on the result of the credential evaluation I could return an 401/Unauthorized status code if credentials provided in the SMS (which is part of the request body) are invalid and process the request otherwise. However, I think that this approach is quite ugly as all incoming requests need to be passed to Flask and invalid requests are not rejected at the level of my Reverse Proxy.
Do you have any ideas about how to approach this issue? What would be a considerable approach with regards to "best practises"? Can I extend NGINX in a way to solve this or should I completely drop NGINX in favor of a "better" proxy?
I do not know much about computer networks but I've been dabbling with flutter and aws lambda.
I have a flutter (dart) code that uses http package to make an http request like the following:
import 'package:http/http.dart' as http
final response = await http.get('https://<address to my lambda function via api gateway>');
final body = response.body;
Looking at the http package in pub.dev, it says that the package is a A composable, Future-based library for making HTTP requests. and does not say anything about TLS(SSL). However, the url I provided in the above code is https generated by aws API gateway. So my question is, in the above code, is it using https or http? If it is using http, it is not secure hence, i need to add another layer of security to prevent hackers such as Man in the middle attack. If it is https, does that mean the data that gets sent is encrypted via TLS, hence I do not need any sort of asymmetric encryption between the client and the server?
I seem to be forced in to using HTTPS with AWS API Gateway. I am only hosting non-sensitive GET requests that do not need to be https.
How do I setup HTTP GET Method?
I am using a custom domain name and pointing to DynamoDB.
According to the FAQ, this is not possible:
[A]ll of the APIs created with Amazon API Gateway expose HTTPS endpoints only. Amazon API Gateway does not support unencrypted (HTTP) endpoints.
https://aws.amazon.com/api-gateway/faqs/#general
I'm using SSL in my whole site so I get errors when I pull video streaming content from my azure media services account. All of the urls I get for origin server streaming content when I publish are http. I need them to be https. Is there anyway I can configure the origin service or something I can do before I publish to make the service serve these requests with SSL?
Unfortunately Windows Azure Media Services (WAMS) doesn't support Https.
The formats for streaming, like HLS, are actually transfer formats like Http. HLS doesn't by nature support HTTPS. Instead it has other content protection mechanisms, WAMS uses HLS + 128-bit AES. All of the content transferred in the stream is encrypted by AES.
Depending on your security requirements, you shouldn't need to serve the requests with https. The request that retrieves the origin locator url should be https already, the request that stores it in your database should be https, the request that provides the url to a client should be https, so with the default AES encryption it's entirely secure.