Jesse, If it is not, then it is a defect. That is the intended functionality.
Thanks, Doug On Fri, Jul 31, 2009 at 10:57 AM, Jesse Stay <jesses...@gmail.com> wrote: > 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 <d...@twitter.com> 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 <jesses...@gmail.com> 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 <4bra...@gmail.com>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 <jesses...@gmail.com> 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 <d...@twitter.com>wrote: >>>>> >>>>>> Well said, Duane. >>>>>> Thanks, >>>>>> Doug >>>>>> >>>>>> >>>>>> On Wed, Jul 29, 2009 at 7:18 AM, Duane Roelands < >>>>>> duane.roela...@gmail.com> 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 <dpr...@gmail.com> 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 >>> >>> >>> >> >
