I want to host an SMS application on GAE and all my traffic will come
from a SMS GATEWAY with a single IP address.
Is that fine(I'm expecting 500 dynamic requests/sec) ?
Will there be any problems like unusual traffic errors or any other issues ?
EDITED
More info:
My users send queries through SMS which will be routed to my app from SMS GATEWAY(single IP address).
My app processes those queries and reply back through SMS (again through SMS GATEWAY).
I can reply using URL FETCH(not a problem) but what i'm worried about is if I receive some 500 dynamic requests/sec from single IP address , GAE might block them thinking them as Dos(denial of service) attack .
GAE either asks the user to enter a captcha at https://www.google.com/accounts/DisplayUnlockCaptcha or redirects to sorry.google.com and displays an error message itseems if it receives unusual traffic from single IP . But my users access app only through SMS.
Please look at this production issue filed.
It would be technically doable - your app can detect the user's IP via the REMOTE_ADDR environment variable, and if it's the one you want, show them the actual page (showing them a 403 otherwise). Your second question is a bit trickier to answer - your App Engine app could handle it assuming you wrote it in a scalable manner (not a trivial assumption!) and if you can afford the amount of traffic you're trying to throw at it.
You're right to be concerned that getting that level of traffic from a single IP might set off some form of DoS protection - it shouldn't, but it's impossible to rule it out. If it were to happen, you could file a production issue, and we'd take care of it.
Related
i have done a security app which locate a iPhone and send the GPS location of the phone through message to an associated number this functions works good until iOS 5, but the issue is sending SMS without users knowledge is restricted in iOS 6, so i need a help here instead of sending message, is there any other possible way or replacement for this function? any answer related to this method are appreciated.
Thank you.
You haven't specified whether your ios app has a server. If yes, you can transmit location to server and that in turn can transmit it to intended user via specific api.
If this is not correct, APNS is your friend. This is a way to send messages to desired devices only, the ones who explicitly registers through your app.
Another quite equivalent option is to store it in public back-end like parse.com. As soon as other devices start your app, they can pull your location from there. If their device is already live, parse.com can make sure to notify them as soon as you change your location value in their DB.
I'm doing https web requests in silverlight using "WebRequest"/"WebResponse" framework classes.
Problem is: I do a request to an url like: https://12.34.56.78
I receive back a versign signed certificate which has as subject a domain name like: www.mydomain.com.
Hence this results in a remote certificate mismatch error.
First question: Can I somehow accept the invalid certificate, and get the WebBresponse content ? (even if it involves using other libraries, I'm open to it)
Additional details: (for those interested on why I need this scenario)
I'm trying to give a client access to a silverlight app deployed on a test server.
Client accesses the silverlight app at: www.mydomain.com/app
Then I do some rest requests to: https://xx.mydomain.com
Problem is I don't want to do requests on https://xx.mydomain.com, since that is on our productive server. For this reason I use https://12.34.56.78 instead of https://xx.mydomain.com.
Client has some firewalls/proxies and if I simply change his hosts file and map https://xx.mydomain.com to 12.34.56.78, web requests don't resolve to the mapped IP.
I say this because on his network webrequests fail if I try that, on my network I can use the hosts changing without problems.
UPDATE: Fixed the problem by deploying test releases to an alternative: https://yy.domain.com and allowing the user to configure for test purposes, the base url to which I do requests to be: https://yy.domain.com.
Using an certificate that contained the IP in the subject or an alternative subject would've probably worked too, but would have cost some money to be issued by a certified provider and would not be so good because IP's might change.
After doing more research looks like Microsoft won't add this feature too soon, unless there's a scenario for non-testing/debugging uses.
See: http://connect.microsoft.com/VisualStudio/feedback/details/368047/add-system-net-servicepointmanager-servercertificatevalidationcallback-property
I'm working with a third party webservice who requires that all calls to their service are made from whitelisted IP addresses. That is, I must give them IP addresses from which I will be making calls to their service.
Problem is I'm using Google Appengine. Is there any way to get a static IP address when making outgoing http requests from Appengine? Failing that - is there a block of IP addresses that all requests will come from? I could get the entire bloc whitelisted. If this exists, how likely is it to change?
I know I could setup a simple Amazon EC2 instance to use as a proxy (will ask another question for how to do this specifically) but just wanted to make sure there was no other way.
I had the same problem a couple of weeks ago connecting via Urlfetch from Google App Engine to the Stack Exchange API (The team has promptly fixed the problem whitelisting all the GAE IPs).
The range of IP addresses that urlfetch connections may come from, can be found by performing the following DNS lookup:
dig -t TXT _netblocks.google.com #ns1.google.com
Last I checked this wasn't possible. You can get the current IP address dynamically, but it isn't predictable.
Please note: _netblocks.google.com is apparently not accurate. Currently I have noticed that GAE connects from addresses not listed when you dig _netblocks, for example from 8.35.201.166.
This range is not listed in _netblocks, _netblocks2 or _netblocks3.
Current dig output:
ip4:216.239.32.0/19
ip4:64.233.160.0/19
ip4:66.249.80.0/20
ip4:72.14.192.0/18
ip4:209.85.128.0/17
ip4:66.102.0.0/20
ip4:74.125.0.0/16
ip4:64.18.0.0/20
ip4:207.126.144.0/20
ip4:173.194.0.0/16
I am using Nokogiri to screen scrape a few websites.
My website is hosted on US servers, and so when it fetches the website, the website responses as if the user was a US user. I need the website to responds as if I was an Australian user, even though the server is located in the US.
When running locally it works fine because locally it responds as if it was Australian.
How can I read the site using Nokogiri as if I was from another country?
You have to run your requests through a proxy in Australia.
This doesn't have anything to do with Nokogiri - it applies no matter how you're trying to scrape a page. HTTP travels over TCP, which is a bi-directional protocol so you can't spoof its IP address. If you tried to spoof the IP address of a TCP packet, you would never get your response back.
You can configure Tor to always use exit nodes from a specific country. Please, however, do not use this method if this will put the Tor network under some serious strain (i.e. fetching the pages continually); in this case please consider buying an (Austrlia-based) annonimizing service (or simply a proxy).
One of my clients uses Trend Micro InterScan Messaging Security to protect their internal mail services.
Suddenly InterScan decided to filter out all messages coming from Google App Engine.
Unfortunately they haven't been able to whitelist the sender address as each e-mail gets a different one. For example, *3ckihSOVMMHlZHSL.JSMMHlZHSL.JS*#apphosting.bounces.google.com, with everything before the # being variable.
Update I'm including this screenshot of how Interscan sees the incoming e-mail. Notice that all senders are different:
If I look into the e-mail headers, the apphosting domain appears inside the Return-Path field:
Return-Path: <36kSiSwYIBh0883XL3E7.5EH883XL3E7.5E#apphosting.bounces.google.com>
The "From" field looks ok. It says what I set it to say, but the spam filter only looks at the Return-Path.
My client sysadmin doesn't want to whitelist the whole apphosting domain, as it wouldn't be only whitelisting my application.
How could I bypass this e-mail filters if I can't get an unique sender?
Thanks,
You can't change the return-path header of mail sent by App Engine. The way I see it, you have two options:
Whitelist everything from App Engine. Spam from App Engine is not a big problem, because it's expensive to send in the huge numbers spammers need, and we're constantly monitoring for spamming and shutting spammers down.
Whitelist based on the X-Google-Appengine-App-Id header, which will be set to the app ID of your app.
I am not well versed in spam filters, but it seems to me that if it can only whitelist based on one field, it is pretty lame. Unfortunately that does not help you. If this is an important client, and they absolutely refuse to budge, I see two possible paths forward:
Do some research into interscan to see if you can give the client some pointers (tactfully) on how to configure it to whitelist in such a way that your mail can get through, but only your mail.
Maintain a server outside app engine specifically for the purpose of sending emails. You can build a super simple web app that just sends out emails, and call it from within your app engine app.