This is a newbie question... I want to create a service which responds to emails sent to it.
Just to illustrate. If a user sends an email to handlethis#example.com with some instructions, I want a program at example.com (which is a domain I own) to read the email and act accordingly.
I strongly doubt I can do this with standard web hosts (which are shared), so I welcome suggestions on where I can host something like this (at the cheapest rate).
What will the "program" be written in? Can I use php, etc or is it some specific "email-handling" language!?
Thanks!
S
FWIW, I think this question should be posed on serverfault.com rather than here.
I confirm this is something most shared hostings can't do: You need to be able to create a scheduled task/cron job which checks your e-mail account every x minutes.
You might consider a virtual server hosting. A bit more pricey but much more flexible.
The script would be written in php on Linux or in VBS/JScript/.NET on Windows. I've written such a script in JScript on Windows, using a component that implements POP3.
Related
I would like to implement a queuing mechanism for sending out email via PHPMailer on Amazon EC2. I have set up Beanstalkd correctly on the server and can access it via a console. The mail doesn't seem to go through (trying the various combinations of sample code). In addition do I need to set up a cron job also that would call one of the producer or consumer files?
Does anyone have working code for sending out email via phpmailer/pheanstalk please for Amazon EC2?
Thanks.
Beanstalkd is great, and I use it myself, however, don't use it for this; It's reinventing the wheel in a bad way. Instead, install a local mail server such as postfix and get that to do your queuing for you. This is also much, much simpler, faster, and easier to control. Email servers are built for managing queues, and they are extremely good at it.
Before you do so, get your mail sending script working – there's no point in even attempting to get something more complex working until you've done that. Also be aware that sending email from EC2 is difficult – Amazon wants you to use their SES service rather than sending directly – you may find sending is blocked altogether. Read the PHPMailer troubleshooting guide to see how to diagnose that.
I'm currently developing a mobile app using Sencha Touch 2 and Phonegap. It's a game where you can "check-in" at some places and get some points every time you do a successful one (as in Foursquare).
I'd like to make it impossible for a clever guy (for example, someone that has decompiled my apk) to execute the REST web service (for example, mywebservice/checkin?access_token=abcde&latitude=12345&longitude=6789) with his computer or any other device outside of the app.
Do you have any idea of how I could achieve this ?
Thanks a lot,
In absolute terms, what you are looking for is impossible - if the app on the device contains the key and code necessary to send a valid message, and the device allows the user to decompile apps, then anyone can theoretically reverse engineer it and send whatever messages they want.
In practical terms though, it isn't worth worrying about - nobody will put that much effort into it, and you can probably detect accounts with suspicious activity fairly easily. Just use https and a simple token from the app code to stop anyone who can see the network activity but won't go as far as digging into the app code.
Couple options (depending on your exact scenario):
Bake user info and the app key into the security API key. This would ensure only valid account holders can use the API. Take a look at OAuth
Monitor per account or per connection service activity and look for any suspicious patterns. For example, if the app is operating in user think time then you would expect low numbers of calls per second.
Here is my scenario: I have an iPhone app (written in Monotouch but that has nothing to do with the design) that has consumables. I give 25 free consumables when the app is installed. If the user deletes the app and re-installs it, he now gets the same 25 free consumables. I need a way to prevent this.
So I came up with the idea of a database on a server (my website host?), which would have a list of UDIDs. If the user's UDID is in the database (that means he has already installed the app) a response is sent back to the app to set the consumable count to zero. If the UDID is not in the d/b, then it is added and the response is so indicated (new app).
I am thinking of using REST (simpler) and a Linux host for the server side. My questions are:
Is there a better way of doing this?
What is the language of choice on the server?
What about sqlREST? (looks very good to me, but will it work in the above scenario?)
Well, I can tell you what MY language of choice would be: ASP.NET/C# in combination with an SQL Server DB. I have my website running at a hoster which offers this combination for just a few bucks per month.
You don't even need webservices. You could just setup an ASPX page on your server and call it using NSString.FromUrl (or whatever the method is called): "mycounter.aspx?udid=1234". Everytime the page gets called, it increases the count of the passed in device ID and the only thing it ever outputs is the number of remaining requests.
Your client parses that response to integer and if it is zero, informs the user.
You should proably add some hashing to make sure that evil Krumelur won't go to your URL and call it for random device IDs, rendering them unusable. :-)
René
The answer really depends on your web host. And what they support. That probably depends on your transaction volume and so on.
Since you are using Monotouch I'm going to assume you are comfortable in .net/c# world.
I would look at a WCF web service written in c#. This in turn would use SQL server for storage. Of course you could just go straight to a SQL server stored procedure.
sqlREST looks interesting but at a glance it looks like you need to be running the Appache + Tomcat stack for that to work.
if you just want the lowest possible bar to get it working then I agree with the other poster... ASP.NET + SQL server would get it done too.
From few months ago when i was using twitter, i was able to send twitter a SMS and when i go home and check my twitter page, i see the SMS i sent is on the website as a tweet. "That was great"
Now, i want to make the same in my website, so someone will send my website SMS as a command and my website will save this command in the db for future processing.
My problem that i don't know where to begin.
1- How users will send from around the world while there are different mobile companies in each country, or thats not a problem?
2- How my website will receive and read these SMS? there is a service for that?
3- Do you know any articles which simplify these tasks for me?
If someone worked on something like that before, please advice, any info will be helpful.
Contact your messaging provider, they will have solutions for each country they support.
In practice these things need to be agreed on a per-country bases (e.g. shortcodes etc), but the providers will do a lot to help.
Depending on what countries you want to cover, a single provider will probably do it - if you need absolutely every country with a mobile network, then you might need several, in which case integration is more complicated.
Typically they send either a HTTP POST, or a SMTP email to your server when they receive a message to your company's shortcode or shortcode prefix. But the integration options that exist are agreed per provider; there is no real standard or de-facto standard.
Well, first of all you need a sms-gateway. This is a service which you can buy a lot of places with varying prices. Your site can communicate with this gateway in different ways depending on the gateway-host.
Now, you can send messages to the number you bought on the sms-server and poll them (or push, again depending on your sms-provider) to your site. Just as with any other sms "IRL", you can use country codes to send a very costly SMS from around the globe. If you wish to keep this price lower, you need to rent a SMS-gateway which is internationalized or you need to rent one in each country...
.. In conclusion, doing this is not really a feasable option for your small "hobby-type" project :) Renting a SMS-gateway is rather cheap though, so the problem is really in your "multiple countries" request ..
I have created a web service for sending and receiving SMS messages. We are connecting through VPN to the SMS gateway of the local GSM operator: they have assigned us an public number as well as the option to send messages worldwide.
It doesn't matter if we send sms worldwide or receive from anyone - it just work :)
International sms might be a bit more expensive to send.
Edit:
theoretically there is a possibility to send sms thgrough an sip provider (like betamax /voipdiscount.com/) but this is not so fast and reliable comparing to traditional service.
I've had some success in the past with http://www.aspsms.com/
This is a paid service (per SMS) and be aware that you need to pay and FAX (yes, FAX...) your identity information to the before you get an API key.
I develop industrial client/server application (C++) with strong real time requirements.
I feel it is time to change the look of the client interface - which is developed in MFC - but I am wondering which would be the right choice.
If I go for a web client is there any way to exchange data between C++ and javascript other than AJAX <-> Web service <-> COM ?
Requirements for the web client are: Quick statuses refresh, user commands, tables
My team had to make that same decision a few months ago...
The cool thing about making it a web application would be that it would be very easy to modify later on. Even the user of the interface (with a little know-how) could modify it to suit his/her needs. Custom software becomes just that much easier.
We went with a web interface and ajax seems the way to go, it was quite responsive.
On the other hand, depending on how strong your real time requirements are, it might prove difficult. We had the challenge of plotting real time data through a browser, we ended up going with a firefox plugin to draw the plot. If you're simply trying to display real time text data, it shouldn't be as big an issue.
Run some tests for your specific application and see what it looks like.
Something else to consider, if you are having a web page be an interface to your server, keep in mind you will need to figure a way to update one client when another changes the state of the server if you plan on allowing multiple interfaces to your server.
I usually build my applications 2-folded :
Have the real heavy-duty application CLI-only. The protocol used is usually text-only based, composed of requests and answers.
Wrap a GUI around as another process that talks to the CLI back-end.
The web interface is then just another GUI to wrap around. It is also much easier to wrap a REST/JSON based API on the CLI interface (just automatically translate the messages).
The debugging is also quite easy to do, since you can just dump the requests between the 2 elements and reproduce the bugs much more easily.
Write an HTTP server in your server to handle the AJAX feedback. If you don't want to serve files, create your server on a non-standard port (eg. 8081) and use a regular web server for the actual web page delivery. Now have your AJAX engine communicate with the server on the Bizarro port instead of port 80.
But it's not that hard to write the file server part, also. If you do that, you also get to generate web pages on-the-fly with your data pre-filled, if you want.
Google Desktop Search does this now. When I search my desktop for 'foobar', the URL that opens is this:
http://127.0.0.1:4664/search?q=foobar&flags=68&num=10
In this case, the 4664 is the Bizarro port. (GoogleDesktop serves all the data here; it only uses the Bizarro port to avoid conflicts with any web server I might be running.)
You may want to consider where your data lives. If your application feeds a back-end database, you could write a web app leaving your c++ code in tact -- the web application would be independent and offer up pages to web users and talk directly to the database -- In this case you have as many options, and more, as you have indicated.