4 ms·

Is Google App Engine blocking PayPal?

25 points by ptm 18y ago

thorax 18y ago
Anyone here independently confirm this yet? Not a good sign from a Google neutrality standpoint. I'll try it tonight if no one else gets a chance.
- thorax 18y ago
  I got a chance to try it out just to see if a simple URL fetch was blocked: http://helloworld-111.appspot.com/ http://helloworld-111.appspot.com/ Locally, this code reports 200 OK for all of those except the last reports a 302 redirect (to the https, I presume). As you can see, on Google, they all fail with an internal exception. Paypal does have a universal Disallow in robots.txt, so I thought I'd setup why.gd to do the same. But it works fine. Anyone else find any other URLs that are blocked?
  - thorax 18y ago
    Looks fixed now. Very fast turnaround. Nice work, Google.
olefoo 18y ago
I notice that noone is even considering the possibility that it's an anti-fraud measure run rampant.
- pmjordan 18y ago
  That was one of my first thoughts, but I would assume that GAE spam-bot abuse would be smarter than that. If there really was someone doing this kind of stuff, surely they would just block that particular PayPal account (along with banning the GAE user) - AFAIK valid PayPal accounts aren't easy to generate in large quantities. And I can't imagine it's a reaction to a GAE-based DDoS attack, as spotting that kind of pattern ought to be really easy and resorting to blocking URLs wouldn't be necessary. To be honest, I suspect this to be a bug rather than deliberate, or else you'd have thought that they'd have notified people.
waldrews 18y ago
Has anybody tried GAE with Amazon FlexPay or another payment service?
timr 18y ago
Not sure what can be done about this, but the URL matching is missing lots of stuff. Posted this five hours ago, with a 1-character difference in the URL: http://news.ycombinator.com/item?id=213784 http://news.ycombinator.com/item?id=213784 (Ordinarily I wouldn't complain, but it's happened about six times in the last 2-3 days.)
- pmjordan 18y ago
  In that particular case, stripping off everything after # would have helped. In general, it's practically impossible to defend against dupes because you can just frivolously add query strings, so http://groups.google.com/group/google-appengine/browse_thread/thread/9059b0750c45703b http://groups.google.com/group/google-appengine/browse_threa... and http://groups.google.com/group/google-appengine/browse_thread/thread/9059b0750c45703b?foo=bar http://groups.google.com/group/google-appengine/browse_threa... aren't dupes, even though they link to the exact same page. There really isn't anything you can do about this particular case except error-prone heuristics.
  - timr 18y ago
    Yeah, it's a difficult problem. In this case, it was a single character that I didn't notice. I'm not even clear on how it got there (or why it wasn't on the second submission URL). Perhaps the "solution" is to ignore query strings....how many sites use them to distinguish content anymore? Alternately...compare the content of the <head> tag on the linked page? That wouldn't be a perfect solution, but it would probably go a long way.
    - pmjordan 18y ago
      The hash is of course for linking sections within the page, so I suspect the culprit is a link you clicked on the page itself before submitting the story. There are a couple of links with href="#" there, although they all have JavaScript event handlers that cancel the default action. Do you have JavaScript disabled by any chance, or do you use some obscure browser? In any case, I think HN should strip the hash and what follows for purposes of dupe detection, but keep them in the link in case someone actually wants to link to a specific spot in the page. To answer your question: query strings ("?foo=bar&a=b&c") are widely used. Among other places, HN itself uses them. :) Also, whenever you submit a form with GET.
icky 18y ago
Can anyone confirm that GAE isn't just dropping SSL requests in general?
- thorax 18y ago
  Yeah, I did a little test above with another https site: http://news.ycombinator.com/item?id=214055 http://news.ycombinator.com/item?id=214055
gstar 18y ago
Fair play to Google, i think, considering PayPal/eBay block Google Checkout on eBay.
- babul 18y ago
  eBay are very monopolistic
Marzia 18y ago
This was a bug with our anti-phishing protections, and we are currently working on a fix: http://groups.google.com/group/google-appengine/browse_thread/thread/9059b0750c45703b/b1d0611dd4b04273 http://groups.google.com/group/google-appengine/browse_threa... Thanks, Marzia
- ucdaz 18y ago
  Whew! Thank God! Almost passed out!
blinks 18y ago
No. Someone from Google responded to that thread noting that it was a bug, and has since been fixed.

25 points by ptm 18y ago

Anyone here independently confirm this yet? Not a good sign from a Google neutrality standpoint. I'll try it tonight if no one else gets a chance.

thorax 18y ago
I got a chance to try it out just to see if a simple URL fetch was blocked: http://helloworld-111.appspot.com/ http://helloworld-111.appspot.com/ Locally, this code reports 200 OK for all of those except the last reports a 302 redirect (to the https, I presume). As you can see, on Google, they all fail with an internal exception. Paypal does have a universal Disallow in robots.txt, so I thought I'd setup why.gd to do the same. But it works fine. Anyone else find any other URLs that are blocked?
- thorax 18y ago
  Looks fixed now. Very fast turnaround. Nice work, Google.

olefoo 18y ago

I notice that noone is even considering the possibility that it's an anti-fraud measure run rampant.

pmjordan 18y ago
That was one of my first thoughts, but I would assume that GAE spam-bot abuse would be smarter than that. If there really was someone doing this kind of stuff, surely they would just block that particular PayPal account (along with banning the GAE user) - AFAIK valid PayPal accounts aren't easy to generate in large quantities. And I can't imagine it's a reaction to a GAE-based DDoS attack, as spotting that kind of pattern ought to be really easy and resorting to blocking URLs wouldn't be necessary. To be honest, I suspect this to be a bug rather than deliberate, or else you'd have thought that they'd have notified people.

waldrews 18y ago

Has anybody tried GAE with Amazon FlexPay or another payment service?

timr 18y ago

Not sure what can be done about this, but the URL matching is missing lots of stuff. Posted this five hours ago, with a 1-character difference in the URL: http://news.ycombinator.com/item?id=213784 http://news.ycombinator.com/item?id=213784 (Ordinarily I wouldn't complain, but it's happened about six times in the last 2-3 days.)

pmjordan 18y ago
In that particular case, stripping off everything after # would have helped. In general, it's practically impossible to defend against dupes because you can just frivolously add query strings, so http://groups.google.com/group/google-appengine/browse_thread/thread/9059b0750c45703b http://groups.google.com/group/google-appengine/browse_threa... and http://groups.google.com/group/google-appengine/browse_thread/thread/9059b0750c45703b?foo=bar http://groups.google.com/group/google-appengine/browse_threa... aren't dupes, even though they link to the exact same page. There really isn't anything you can do about this particular case except error-prone heuristics.
- timr 18y ago
  Yeah, it's a difficult problem. In this case, it was a single character that I didn't notice. I'm not even clear on how it got there (or why it wasn't on the second submission URL). Perhaps the "solution" is to ignore query strings....how many sites use them to distinguish content anymore? Alternately...compare the content of the <head> tag on the linked page? That wouldn't be a perfect solution, but it would probably go a long way.
  - pmjordan 18y ago
    The hash is of course for linking sections within the page, so I suspect the culprit is a link you clicked on the page itself before submitting the story. There are a couple of links with href="#" there, although they all have JavaScript event handlers that cancel the default action. Do you have JavaScript disabled by any chance, or do you use some obscure browser? In any case, I think HN should strip the hash and what follows for purposes of dupe detection, but keep them in the link in case someone actually wants to link to a specific spot in the page. To answer your question: query strings ("?foo=bar&a=b&c") are widely used. Among other places, HN itself uses them. :) Also, whenever you submit a form with GET.

icky 18y ago

Can anyone confirm that GAE isn't just dropping SSL requests in general?

thorax 18y ago
Yeah, I did a little test above with another https site: http://news.ycombinator.com/item?id=214055 http://news.ycombinator.com/item?id=214055

gstar 18y ago

Fair play to Google, i think, considering PayPal/eBay block Google Checkout on eBay.

babul 18y ago
eBay are very monopolistic

Marzia 18y ago

This was a bug with our anti-phishing protections, and we are currently working on a fix: http://groups.google.com/group/google-appengine/browse_thread/thread/9059b0750c45703b/b1d0611dd4b04273 http://groups.google.com/group/google-appengine/browse_threa... Thanks, Marzia

ucdaz 18y ago
Whew! Thank God! Almost passed out!

blinks 18y ago

No. Someone from Google responded to that thread noting that it was a bug, and has since been fixed.