[twitter-dev] Re: Can OAuth approval process work in an IFRAME?

2009-03-23 Thread Matt Sanford
Hi all, I want to add one comment on this. If you can IFRAME it, you can click-jack it using the opacity, z-index, some CSS positioning tricks. Allowing the 'Yes, I want free porn' button to auto-authorize someone's app to post as a user is a Bad Thing™. I saw the popup flow from

[twitter-dev] Re: Can OAuth approval process work in an IFRAME?

2009-03-21 Thread Ivan Kirigin
Scott is correct here. As a policy, web sites should never allow sign in through an iframe, as even the minority of users smart enough to verify the source URL is twitter.com can't verify it. Ivan http://tipjoy.com On Mar 20, 11:24 pm, Scott Carter scarter28m-goo...@yahoo.com wrote: I think

[twitter-dev] Re: Can OAuth approval process work in an IFRAME?

2009-03-21 Thread Brooks Bennett
I whipped up a quick and dirty fix. Need to clean it up more, but it works (this demo is subject to come down in the very near future)... The page is: http://tweetchat.com/iframe Load it into an iFrame with the following tacky script: iframe src=http://tweetchat.com/iframe/;

[twitter-dev] Re: Can OAuth approval process work in an IFRAME?

2009-03-20 Thread Ivan Kirigin
I'd love to be able to do this also, and have mentioned it off the list. Imagine a Twitter Connect button, which would be a tiny iframe loaded from twitter.com. If signed in, the token exchange could take place right there. If not signed in, a new window could load with the regular OAuth

[twitter-dev] Re: Can OAuth approval process work in an IFRAME?

2009-03-20 Thread Abraham Williams
If you have the approval process take place in the iframe there is no way to for the user to actually verify they are interacting with twitter. if they are not logged into twitter already you are then asking users to enter username/password on a potentially unsafe site and opening up to fishing.

[twitter-dev] Re: Can OAuth approval process work in an IFRAME?

2009-03-20 Thread Scott Carter
I think Ivan's suggestion could answer the concern about the case where a user needs to enter a username/password: If not signed in, a new window could load with the regular OAuth process. For the case where the user is already logged in, there doesn't appear to be any risk here. Consider the