Hacker News Reader

Comment by talldan | Hacker News Reader

This isn't a new thing, it's been possible for a number of years to integrate paypal using an iframe.

Hands-up - I'm guilty of doing this. I hadn't really considered the issue before, but I agree it is a security concern.

One of the reasons developers switch to using an iframe rather than a separate window is due to popup blocking. Retrieving the url for a payment system usually requires making a server side call, so it's impossible to then launch a popup directly from the user action. The solution would be to require a second user action after having retrieved the url.

A complete redirect isn't always the best case for single page web apps, either. Thankfully, we're a bit smarter about deep-linking these days, so that should no longer be an issue.

View on HN

>This isn't a new thing, it's been possible for a number of years to integrate paypal using an iframe.

Yes, I know about classic integration options. But it's not about what was possible (any kind of phishing is always possible) it's about what Paypal suggests by default and what websites actually use.

> Retrieving the url for a payment system usually requires making a server side call

window.open('site.com/get-url-for-paypal-then-redirect')?

that's a good option - hadn't considered that approach.

Yeah, and it's very widely used in oauth. (Talking in separate threads is weird)

Or even just a regular link to site.com/get-url-for-paypal-then-redirect.

Don't most competent popup blockers actually allow popups which are implemented plainly as links with a different target? I mean, the popups you want to block are only the ones which don't result in a single window/tab opening directly based on a user input where you would expect a popup to result.

yes - as I mentioned above, it's impossible to do this in one step, though. It requires getting the url from a server-side call, and then rendering the link to that url. Since the pressure is on to reduce friction in the process, you can see why this has been reduced to using an iframe (which can launch seamlessly in a single button press).

If by "server-side" call you mean getting a token for Express Checkout, I don't see how it's different from any existing OAuth implementation where site.com/oauth/twitter redirects to twitter.com/?oauth_token=TOKEN. That's the best practice actually.

Shameless plug - i have an article on paypal's oauth which is similar to oauth1 but hasn't fixed it's token fixation bug yet: http://homakov.blogspot.com/2014/01/token-fixation-in-paypal...

Reply on news.ycombinator.com