SMS Gateway

Hey! It aint that hard!

SMS Gateway

Postby Dark Shadow » 02/26/09, 6:07 am

I'm building an SMS gateway in preparation to building the Uptime monitoring software so it can be used with other applications I may develop in the future. The timeline on this is 5 days. Features include:

1) Send text messages from GET requests.
2) Automatic exchange detection. No need to define carrier. Exchanges are updated nightly.
3) Configurable reply phone number or email.
4) Single message sending via a web page.
5) Normal mode enables sending text messages using your account key. Secure mode requires your account key and an MD5 key created from your account email address, password and the recipient's phone number and thus will change every time you send a message to a different user.

This will be exactly like http://www.txtdrop.com except with an API and it won't slow down messages. API access will require a paid account, however, ShellCity members are welcome to free accounts for their own applications.

The API access will also provide exchange lookup codes in the event you want to write your own app for sending text messages and just need the exchange information.

International number recognition SMS gateway is a future project as is GSM modem texting failover if the number is ported...
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby Dark Shadow » 02/26/09, 6:55 am

Proof of concept:
Code: Select all
http://www.deltaend.net/smsgateway.php?email=name@domain.com&area=763&phone1=555&phone2=1234&body=message%20here

URL: http://www.deltaend.net/smsgateway.php

Get Variables:
email : Your email or 10 digit phone number you want replies to be sent to.
area : Area code of the recipient.
phone1 : First 3 digits of the recipient's phone number.
phone2 : Last 4 digits of the recipient's phone number.
body : Message body goes here.

This is a free version of the software that I'm building. It is a proof of concept only and will not be updated. It does not include security but it does contain governing code to prevent spamming, abuse and corporate use.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby SOD » 02/27/09, 2:12 pm

WOW all that in a get?
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Dark Shadow » 02/27/09, 5:06 pm

Yes dear little SOD... all of that in a GET.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby SOD » 02/27/09, 5:13 pm

I'm sure you would not want to use post. :roll:
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Dark Shadow » 02/27/09, 5:49 pm

Do you have any constructive comments or do you just enjoy trolling for my posts?
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby SOD » 02/27/09, 7:06 pm

A little from column A and a little from column B.
Being honest for the sake of transparency. :arrow:

Since you can't use a Get in production what is the secure layer going to look like? 128 or 256? Not trying to be anything but curious about the security. Are you going to get a cert?
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Gerry » 02/28/09, 10:27 pm

Does it need to be secure? He could just pitch it as a non secure texting service. I can't see anything wrong with that.
Gerry
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5727
Joined: 12/04/01, 12:00 am
Location: Perth, Western Australia

Postby SOD » 02/28/09, 11:35 pm

With the get handling the phone number there might be an issue with privacy if the receiver has non published/unlisted number. Does the end user own that phone number or does it belong to the phone company?

On a positive note it would be nice to have an sms service that allowed me to wite a custom app for it
then apply the service/backend.

To begin with though shouldn't the get be a post?
That would get the security thing off to a good start.
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Dark Shadow » 03/01/09, 4:47 am

SOD wrote:With the get handling the phone number there might be an issue with privacy if the receiver has non published/unlisted number. Does the end user own that phone number or does it belong to the phone company?

On a positive note it would be nice to have an sms service that allowed me to wite a custom app for it
then apply the service/backend.

To begin with though shouldn't the get be a post?
That would get the security thing off to a good start.


PayPal API access is processed via SOAP which is basically a GET request with array type responses. This includes the person's credit card information directly in the GET request itself. I can understand how POST might be considered more secure due to the fact that information is encoded into the communication vs the url, however, I believe this could negatively impact the simplicity of application design for such a service. Any thoughts on this SOD?

As it stands, users will be able to select a 'secure mode' in which all of their requests to send email to a recipient will be MD5 encoded (MD5, not because it is the most secure but the easiest to generate cross platform) with their username, password, and recipient phone number.

I suppose I could add a public/private key type deal for sending messages but this would seem to be overkill for such an application considering that text messaging is less secure than email as it stands.

I do plan to add a standard 128bit security cert on the website of course. Any marketable website automatically gets a decent cert in my opinion, however, this is more to protect transactions of the website than it is to protect the API communication, although it would seem to have a nice secondary effect.

Due to the 150 character limit with most texting, I figure this service will be mostly used to notify people of various events such as, "Your table is ready for 2," or "Your server5 is offline, " or "Your account is overdue," or "Home Alert! Call security center," etc...
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby SOD » 03/01/09, 1:38 pm

*sigh*
Don't confuse a HTTP Request with SOAP. PayPal does not use a get to transfer CC info. Dark, no one uses a simple GET to do any sensitive work.

From the PayPal API

"The FORM tag includes two required attributes, action and method, which always looks like
this:

"FORM action="https://www.paypal.com/cgi-bin/webscr" method="post"

IMPORTANT: Do not change these values.These attributes are required for all Buy Now
buttons, shopping cart buttons, and Donate buttons."

Continued from the API reference.

"EXAMPLE 11.1 HTML Code for FORM Prepopulation
Code: Select all
form action="https://www.paypal.com/cgi-bin/webscr" method="post"
input type="hidden" name="cmd" value="_cart"
input type="hidden" name="business" value="seller@designerfotos.com"...
/form
"

Please note that both requests require POST. A standard for this API. Do not confuse this with a simple request. You are making generalizations that will mislead you.

What you want to accomplish is interesting. But please understand the effort involved to get it into production. This involves some layers. Also see if SOAP is right for you.

References:
The Soap Spec -
http://www.w3.org/TR/soap12-part1

The Pay Pal Website Payments Standard Integration Guide
https://www.paypal.com/en_US/pdf/PP_Web ... nGuide.pdf

You are looking for Chapter 11 HTML Form Basics for Website Payments Standard.

Given a small load in a trusted environment your model works. The issues are scale and scope.

You have built a working analogy of a concept.
Next you need to understand that the code you have now is NOT the code you will end up with. For that matter how the code accomplishes its task may change depending on security, capacity,
velocity of load and total load. There are also other factors that are unknown but you do an assessment to get you in the ballpark.

Guys, I think security is huge because there are so many lawyers (looking your way Bob :D) and so many nut cases. That is what security means here,
case management. The potential for abuse is high
outside the trusted environment.

The real work here is unit testing in a ongoing
methodology. I think apps like this are good candidates for Agile. The perpetual nature of Agile driven with capacity/load metrics from the application would produce builds that would capture and solve capacity/load anomalies. You can literally match the velocity of development
to capacity/load metrics. After a while you have an app that "looks like" the traffic it serves and it's
ability to grow.

I wish I had the time to get involved the above paragraph would make an interestingstudy.

Now i have headache cause I had to be an adult.
Going to Hulu now.
It is better to be here than there - SOD
SOD
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5284
Joined: 12/06/01, 12:00 am
Location: here and there

Postby Dark Shadow » 03/01/09, 4:23 pm

SOD,

Good post, but I wasn't referring to the standard Paypal site integration where you send POST variables off and then you get kicked off to the Paypal site, I was talking about their API integration for running credit cards using Website Payments Pro.

https://cms.paypal.com/us/cgi-bin/?cmd= ... PAPIBasics

This is what a normal Website Payments Pro string looks like:
Code: Select all
$nvpstr="METHOD=$method&VERSION=$version&PWD=$pwd&SIGNATURE=$signature&USER=$user&&AMT=$amount&CREDITCARDTYPE=$creditCardType&ACCT=$creditCardNumber&EXPDATE=".         $padDateMonth.$expDateYear."&CVV2=$cvv2Number&FIRSTNAME=$firstName&LASTNAME=$lastName&STREET=$address1&CITY=$city&STATE=$state".
"&ZIP=$zip&COUNTRYCODE=US&CURRENCYCODE=$currencyCode&PROFILESTARTDATE=$startdate&BILLINGPERIOD=$billingperiod&BILLINGFREQUENCY=$billingfrequency&TOTALBILLINGCYCLES=$totalbillingcycles&DESC=$desc&MAXFAILEDPAYMENTS=2";

$url = https://api-3t.sandbox.paypal.com/nvp . $nvpstr;


However, it appears that Paypal then re-decodes the string into an associative array before tossing off the variables in a POST request via CURL. At first glance it looked like they used GET but you are correct that they eventually toss it off as a POST request. It seems odd to me that they build a URL at all though.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby Dark Shadow » 03/01/09, 6:04 pm

Dark Shadow wrote:SOD,

Good post, but I wasn't referring to the standard Paypal site integration where you send POST variables off and then you get kicked off to the Paypal site, I was talking about their API integration for running credit cards using Website Payments Pro.

https://cms.paypal.com/us/cgi-bin/?cmd= ... PAPIBasics

This is what a normal Website Payments Pro string looks like:
Code: Select all
$nvpstr="METHOD=$method&VERSION=$version&PWD=$pwd&SIGNATURE=$signature&USER=$user&&AMT=$amount&CREDITCARDTYPE=$creditCardType&ACCT=$creditCardNumber&EXPDATE=".         $padDateMonth.$expDateYear."&CVV2=$cvv2Number&FIRSTNAME=$firstName&LASTNAME=$lastName&STREET=$address1&CITY=$city&STATE=$state".
"&ZIP=$zip&COUNTRYCODE=US&CURRENCYCODE=$currencyCode&PROFILESTARTDATE=$startdate&BILLINGPERIOD=$billingperiod&BILLINGFREQUENCY=$billingfrequency&TOTALBILLINGCYCLES=$totalbillingcycles&DESC=$desc&MAXFAILEDPAYMENTS=2";

$url = 'https://api-3t.sandbox.paypal.com/nvp' . '/?' . $nvpstr;


However, it appears that Paypal then re-decodes the string into an associative array before tossing off the variables in a POST request via CURL. At first glance it looked like they used GET but you are correct that they eventually toss it off as a POST request. It seems odd to me that they build a URL at all though.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Postby Gerry » 03/02/09, 1:57 am

POST isn't more secure than GET, POST just makes the location of the data a little less obvious. You need encryption if you want security.

As for the need for security due to privacy of receiver's "non published/unlisted number"... yeah I guess so. Although, depending on the message, it would be difficult/impossible to link reciever identities to phone numbers in this system even if the data were to fall into the wrong hands. The attacker would only know of the number's existence. Although I'd imagine there are better ways to make a listing of allocated phone numbers.
Gerry
BIG GIANT HEAD I Get Free Beer
BIG GIANT HEAD I Get Free Beer
 
Posts: 5727
Joined: 12/04/01, 12:00 am
Location: Perth, Western Australia

Postby Dark Shadow » 03/02/09, 3:12 am

Gerry wrote:POST isn't more secure than GET, POST just makes the location of the data a little less obvious. You need encryption if you want security.

Well, it depends. POST data is always encrypted within SSL if the server runs a certificate and you request the data via https, however, GET requests toss the information directly into the URL which, if I am not mistaken, is not encrypted at all even over encrypted SSL connections. Someone listening on a network and sitting between you and the target could see the information passed. Now, if you placed the GET variables inside of an actual connection to a server instead of passing them into the URL, you would get the information encrypted via SSL, however, most people would never do this since it requires more than your average amount of coding to do so.

As for the need for security due to privacy of receiver's "non published/unlisted number"... yeah I guess so. Although, depending on the message, it would be difficult/impossible to link reciever identities to phone numbers in this system even if the data were to fall into the wrong hands. The attacker would only know of the number's existence. Although I'd imagine there are better ways to make a listing of allocated phone numbers.


If the person has an unlisted number than people are far more likely to sequentially dial them then they are to 'discover' them by sitting between your server and mine and sniffing them out. Also, just because you have a number doesn't mean you have other information such as the person's name, address, etc... which is the only purpose behind keeping numbers unlisted, not to hide the existence of that number itself (it is kind of obvious that your number exists). My main concern is to make sure that if you pay for an account, no one else is able to use it without your permission to send data. Also, the messages themselves might be a little more sensitive than the phone number.

I guess at the end of the day I'll probably support both GET and POST and I'll leave it to the programmers to design systems that reflect their desire for security. I can only be responsible for correct delivery and handling of information AFTER it has been handed to my server.
Dark Shadow
Senior Member (Entitled To Root Beer)
Senior Member (Entitled To Root Beer)
 
Posts: 860
Joined: 12/09/01, 12:00 am

Next

Return to Play With Code

Who is online

Users browsing this forum: No registered users and 1 guest

cron