ebay + Paypal : privacy failures and unfriendly websites

I bought something on ebay this morning (a 60-year old book). That’s not particularly exciting. But in the process of trying to pay for it, I had several observations.

1. Finding and buying the item on ebay was fairly straight-forward. I’m not sure why the item didn’t show up in the main search results, but several acceptable options did show up in the “Here’s what people have in their stores” section. Good enough.

2. ebay continues to try to force everything through Paypal. I was going to do that this time anyway, but the lack of choice is below average.

3. ebay and Paypal are still run as separate sites. So when I click on checkout from ebay, it sends me over to Paypal. That’s the theory anyway. Instead I get a giant error message telling me that Paypal has experienced an error and that I should wait and try again.

So I wait. And try again. And it fails again.

I wait some more. Same error. “Odd,” I think.

Months ago (years maybe) I started configuring my web browsers to only allow cookies back to the source domain. This is mostly a privacy protection attempt as it keeps volumes of advertising cookies from being accepted.

On occasion some site exhibits bad behavior by relying on these cross-domain cookies. Wondering if ebay/Paypal is one of these errant sites, I dig into my browser’s cookies.

Sure enough, cookies that are shared between ebay.com and paypal.com have been refused. I enable just the select cookie and try the checkout again. Now it works.

While reviewing all the cookies, there were more than a dozen various advertising cookies that ebay also tried to set. This merely justifies my general decision to block such things.

The failure here is really two-fold. One is not having a better way to hand off the session data between domains — something in the url would seem appropriate enough.

The second is having an unhelpful, misleading error message.

4. Lastly, Paypal still, after all these years, refuses to let me set a credit card as my default payment method, instead forcing me to go through several clicks and multiple pages to override it for each purchase.

I’m reminding yet again why I buy from ebay and use Paypal so infrequently. It’s just a hassle.

Rails 500 error - IP spoofing attack

Apparently Rails 2.1 has the nifty ability to throw a 500 Internal Server Error with the message “IP spoofing attack?!” under certain circumstances.

Unfortunately, those circumstances include a common Apache/Mongrel deployment and Yahoo’s crawler, Slurp, trying to index your site. It’s possible Apache/Mongrel isn’t required; I’m unsure.

The key is that Slurp includes both a Client-IP header (HTTP_CLIENT_IP by the time it hits Rails) and an X-Forwarded-For header (HTTP_X_FORWARDED_FOR). When both are present, Rails assumes something evil is happening and voluntarily dies. Neat.

Such a header can be relied on only if it was set by a trusted proxy. Otherwise, it’s hard to know if it was spoofed. The difficulty is for Rails to know which one, if any, was set by a trusted proxy.

I deploy Rails in a common Apache w/mod_proxy_balancer and Mongrel setup. Apache uses X-Forwarded-For natively, so that’s the one I want to trust. To make Rails happy, I’ve just told Apache to delete the Client-IP header if present.

Adding RequestHeader unset Client-IP to the virtual host configuration seems to do the trick.

This does require mod_headers to be enabled in Apache.