In our company we have omni channel gateway sending sms to end-users. Our platform could handle http requests but one of our client asking for smpp request as they can send only smpp request. So what should I do to receive that request and forward it to our platform (built on laravel and python) through api.
Related
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?
Consider the case where there exists a simple client-server web application where the client sends requests to the server. If the server sends a request to an external API, what IP and header values will be detected by the API? The ones of the client that first send the request to the server, or the ones of the server?
Only the actual IP that makes the request will be visible to the API. So if there is a chain of requests, only the last request IP will be accessible to the receiving party.
I am developing an app that communicates with an API server secured with HTTPS. How can I check whether the requests are actually encrypted in transit? Are there any tools that can intercept the requests?
If I get the connection details from a service provider who needs the ESME to talk to SMSC in SMPP, do I need to have my own SSMP server running on my machine too? Or can I just build a client to connect to SMSC And send SMS? I am using JSMPP to send sms.
To send SMS through a provider, all you need an ESME which will connect to the SMSC of the provider. This is independent of SMPP library you are using.
If you want to test your ESME and the SMS(s) the ESME is sending, you would be better of with your own SMSC.
When trying to use WCF with NetHttpBinding on IIS 8 Express, the following WebSocketException is thrown on client side when the client attempts to connect:
WebSocket upgrade request failed. Received response status code '200 (OK)', expected: '101 (SwitchingProtocols)'.
Google Search is not helpful.
What could be the cause of this error?
It means the HTTP server does not support WebSockets on that URL. During a WebSocket negotiation, a standard HTTP 1.1 GET request is sent to the server with a special Upgrade: websocket header to let the server know that the client wants the connection to use a WebSocket and not HTTP. If the server supports WebSockets, and the request headers are valid, the server is required to send a 101 reply to let the client know that the server is switching the connection over to a WebSocket for the duration of the connection. Any other reply other than a 3xx redirect means means the server does not recognize or allow the Upgrade request on that URL.