Doug, interesting - I didn't realize that's what Sign on With Twitter did. Last I tried that wasn't working though - is that working now? Jesse
On Fri, Jul 31, 2009 at 1:31 PM, Doug Williams <[email protected]> wrote: > Jesse, > That is not true. With the Sign in with Twitter flow (not the standard > OAuth flow which is also available) -- If the user is logged in and has > previously approved the app, they will be immediately redirected back to the > application without ever seeing a Twitter dialog. > > Thanks, > Doug > > > On Fri, Jul 31, 2009 at 9:31 AM, Jesse Stay <[email protected]> wrote: > >> No, Sign in with Twitter doesn't have the same flow as Facebook Connect. >> With Facebook Connect, once your sessions are created, they remain for that >> user for a given time. The user doesn't have to go through the entire login >> process again each time you request a signature for them. With Twitter, the >> user has to go to an *entirely* different page, log in if they haven't, >> click accept or decline, and then come all the way back to your site, *every >> time*. >> I also don't get why you think Facebook Connect is difficult to debug. >> Sounds like more an issue of education than not. I've had worse issues >> with OAuth debugging, to tell you the truth. All the methods are provided >> for you in Facebook Connect to know exactly what's going on - it's actually >> very simple compared to the work I've done with OAuth, and the user never >> has to leave my site to login. With OAuth, there's no way of verifying if >> your URL was written correctly, or what the issue was when tokens weren't >> returned. With Facebook, all that work is done for you, no coding necessary >> on your end until the user is authenticated. It's incredibly simple. >> >> Jesse >> >> >> On Fri, Jul 31, 2009 at 2:21 AM, Abraham Williams <[email protected]>wrote: >> >>> Personally I've found JavaScript based auth systems like Facebook Connect >>> and Google Friend Connect to be very difficult to debug and use. I am also a >>> lot more comfortable with PHP then JS. >>> >>> As far as UX. Sign in with Twitter has the same flow as FBC and GFC. >>> Click a link on your site, jump to provider to authorize, and return to >>> consumer. >>> >>> Abraham >>> >>> >>> On Thu, Jul 30, 2009 at 22:12, Jesse Stay <[email protected]> wrote: >>> >>>> I understand the reasoning behind OAuth, and think it's a step in the >>>> right direction, but, does Twitter have plans to improve and move to a >>>> better Auth system than OAuth? With Facebook Connect I just have to click >>>> once, and if the user is already logged in and approved my app, they never >>>> see the Facebook login box again. Where as with Twitter there are 3 points >>>> of potential failure every single time the user logs in. It's a Ux >>>> nightmare, IMO. While it does solve a problem, I don't think OAuth is the >>>> end or ideal solution. Are there plans to improve this process? >>>> Jesse >>>> >>>> >>>> On Wed, Jul 29, 2009 at 1:05 PM, Doug Williams <[email protected]>wrote: >>>> >>>>> Well said, Duane. >>>>> Thanks, >>>>> Doug >>>>> >>>>> >>>>> On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> First, let me state from the start that I am no fan of OAuth, >>>>>> Twitter's implementation of it, or the way that they've behaved with >>>>>> regard to it. Now, with all that being said. >>>>>> >>>>>> If your website expects me to hand over my Twitter password, I'm not >>>>>> using your web site. Just yesterday, another scam site (TwitViewer) >>>>>> managed to steal thousands of accounts, and convince other people to >>>>>> hand over their information because it was posting tweets from the >>>>>> stolen accounts. >>>>>> >>>>>> OAuth is not perfect, but it provides individual users and Twitter >>>>>> with a way to identify bad actors and lock them out of the ecosystem. >>>>>> >>>>>> OAuth works. There are examples out there. There are developers who >>>>>> are willing to help you. >>>>>> >>>>>> Implementing OAuth tells your customers that the security of their >>>>>> account is important to you, and shutting down Basic Auth trains your >>>>>> users to stop giving away their password. If your product has value, >>>>>> and you clearly communicate what that value is, the users will use >>>>>> OAuth. >>>>>> >>>>>> >>>>>> >>>>>> On Jul 29, 9:10 am, Dewald Pretorius <[email protected]> wrote: >>>>>> > It would not surprise me at all if using OAuth resulted in fewer >>>>>> > signups. >>>>>> > >>>>>> > Potential technical advantages of OAuth aside, every additional >>>>>> click >>>>>> > that you add in the conversion process adds an addition leakage >>>>>> point >>>>>> > where some users can and will abandon the signup process. >>>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Abraham Williams | Community Evangelist | http://web608.org >>> Hacker | http://abrah.am | http://twitter.com/abraham >>> Project | http://fireeagle.labs.poseurtech.com >>> This email is: [ ] blogable [x] ask first [ ] private. >>> Sent from Madison, Wisconsin, United States >> >> >> >
