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.
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?
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.
I'm accessing my email address via imap protocol using Java Mail.
The server name I'm using is something like impa.somename.secureserver.net
Dose this mean I'm consuming messages using a secure channel? how can I verify this?
If your program is using the "imaps" protocol, has set the "mail.imap.ssl.enable" property, or has set the "mail.imap.starttls.required" property, then you're using a secure channel.
You can verify what JavaMail thinks it's doing by enabling JavaMail session debugging and examining the debug output. It's possible to configure things so that it looks like it's using a secure channel, but it really isn't, but that's not likely to be done by accident. For complete verification, you'll need to get a packet sniffer.
Is it possible to connect to an Exchange server using the MailCore2 framework? The documentation does not discuss Exchange Server support.
I want to build my own email client which can connect to the Exchange Server and replace Outlook. Can I use the MailCore2 framework?
If your Exchange server has enabled IMAP support, you can connect to the Exchange server using IMAP with MailCore2. This does not require any licence from Microsoft.
In the docs for the Google Channel API it says:
"A channel is a one-way communication path through which the server sends updates to a specific JavaScript client identified by its Client ID."
In their diagrams they show a client sending its state with a POST. This seems like it would be slow. Can the client communicate with the Channel API through a socket? Or must it send via POST?
POST is a message type indicator and message format.
Major edit after more research!
See Google API doc
Looks like messages from the browser to the server do indeed open new HTTP-level connections to send a POST message. Whether a new TCP/IP connection is needed or not depends on the browser's management of TCP connections--new browsers do a better job of this. See wikipedia HTTP persistent connection
Re: This seems like it would be slow. Usually the browser traffic is asymmetrical--with most of the data from the server to the browser. Comet will help that use case.
Re: Can the client communicate with the Channel API through a socket? Do you mean IP socket? Browsers don't have an api for that. Do you mean "web socket?" I'm 98% sure it wouldn't work to combine the two techniques. But you could try...