> Not sure if pushing oAuth for desktop is actually a Good Thing (tm) or
> an exercise in purity for purity's sake, UX be damned.
I think you hit the nail on the head. Sorry for that outburst
before. I love you Twitter.
I'm happy to jump through hoops on the client side and invent some new
sta
We were thinking six months, but we'll be flexible. If there aren't
good solutions for common use cases, we'll punt a bit.
On Tue, Feb 17, 2009 at 13:12, atebits wrote:
>
>> According to the FAQ, it's going to be deprecated after six
>> months:http://apiwiki.twitter.com/FAQ#WhenwillTwittersuppo
Hey Chris,
> Popping up a browser control inside the app (on the iPhone
> WebKit allows you to do this) appears to be a superior (but still
> kinda weak) solution, with no loss in actual security.
The loss in security is that the user has no way of knowing if they're
actually seeing the Twitter/
> From my chair, OAuth is a fantastic solution to authenticate *other
> web apps*. OAuth anywhere else, desktop, iPhone, laundry machine,
> makes me want to chip away a hole in my skull with a dull screwdriver,
> jab a straw into my head, and drink my own brain matter.
Agree!
> Hell, it's not e
On Tue, Feb 10, 2009 at 7:10 AM, Chris Scott wrote:
>
> See the Darkslide iPhone app for a nice implementation of this. When
> you touch the log in button it opens mobile Safari where you log in
> and authorize the app. Mobile Safari then closes and you are taken
> back to Darkslide where you a
> > No, seriously. When I launch a desktop app, I want to type in my
> > username and password. That's it. If I launch a Twitter client on my
> > iPhone, I don't want to have to quit the frickin' app to authenticate
> > in Safari, then go *back* to the app when I'm done. Sure I could
> > bring
On Feb 9, 2009, at 10:07 PM, atebits wrote:
>
>> For an end user, OAuth is generally speaking much friendlier for
>> pretty much
>> every application type, iPhone, desktop, or web.
>
> From my chair, OAuth is a fantastic solution to authenticate *other
> web apps*. OAuth anywhere else, deskto
> For an end user, OAuth is generally speaking much friendlier for pretty much
> every application type, iPhone, desktop, or web.
>From my chair, OAuth is a fantastic solution to authenticate *other
web apps*. OAuth anywhere else, desktop, iPhone, laundry machine,
makes me want to chip away a ho
The consumer key and consumer secret are required to open the
conversation with Twitter. How can this be handled with a desktop app
unless the app talks to a web proxy? You wouldn't embed the key/
secret in the code (especially if it's open source).
On Feb 9, 1:12 pm, Blaine Cook wrote:
> On
> For an end user, OAuth is generally speaking much friendlier for pretty much
> every application type, iPhone, desktop, or web.
Citation please :)
--
personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai..
For an end user, OAuth is generally speaking much friendlier for pretty much
every application type, iPhone, desktop, or web. The only applications that
might possibly have a usability barrier (and as I said before, a quite
slight one if you just make your own workaround as I just suggested) are
c
Those are all technical issues. I'm talking about usability issues for
non-technical users. However, none of what I'd have to say is
different than what I've already said on the topic, and I'm sure
things will work out fine in time.
--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
S
Assuming Twitter keeps to a long/no expiration model for the OAuth tokens
(as I understand it, it currently is set to not expire in the beta), or
better yet, have a choice method for how long the token will last, for users
accessing a site that accesses twitter, have a short expiration (an hour or
I still maintain that this works fine for knowledgeable web dev folks
(who seem to be the people who get excited about OAuth), but *will*
confuse users who don't understand the tech involved, and/or aren't
comfortable jumping between apps. In addition, the process becomes
even more problematic wit
> > It's not clear to me how desktop apps will authenticate. _Will each
> > author need to maintain a website to perform the authentication? _I
> > don't see how it can be done otherwise.
>
> OAuth was designed with explicit desktop application support in mind.
> To see how it works in practice,
On Feb 9, 4:37 pm, Shannon Whitley wrote:
> It's not clear to me how desktop apps will authenticate. Will each
> author need to maintain a website to perform the authentication? I
> don't see how it can be done otherwise.
OAuth was designed with explicit desktop application support in mind.
To
> It's not clear to me how desktop apps will authenticate. Will each
> author need to maintain a website to perform the authentication? I
> don't see how it can be done otherwise.
Certain apps that have a web view potential could do it by redirecting to
the provider, but yes, this is the point
It's not clear to me how desktop apps will authenticate. Will each
author need to maintain a website to perform the authentication? I
don't see how it can be done otherwise.
On Feb 6, 9:52 pm, Matt Sanford wrote:
> Hi all,
>
> We launched our OAuth code to production yesterday with employ
Hi Jesse,
Currently we don't have any plans to expire access tokens. That
may change in the future but even if it does I suspect it will be a
long duration.
Thanks;
— Matt Sanford
On Feb 7, 2009, at 10:20 PM, Jesse Stay wrote:
How long do the access tokens last? Are they permanent,
Great news, can't wait to start learning about it, and implementing it
in Hahlo. A PHP example, even a very basic one, would be very much
appreciated as I've never worked with OAuth before. Looking forward to
hearing more details in the next week or so.
thanks
Dean
How long do the access tokens last? Are they permanent, or do they have an
expiration after which we'll have to re-authenticate the user?
Thanks,
Jesse
On Fri, Feb 6, 2009 at 10:52 PM, Matt Sanford wrote:
>
> Hi all,
>
>We launched our OAuth code to production yesterday with employee-
> on
Awesome, thanks!
I'll try to post some Python / Django code as we get things working
for Tipjoy.
Ivan
http://tipjoy.com
On Feb 7, 12:52 am, Matt Sanford wrote:
> Hi all,
>
> We launched our OAuth code to production yesterday with employee-
> only access to check for any problems that didn
Hi all,
We launched our OAuth code to production yesterday with employee-
only access to check for any problems that didn't show up during our
testing. We've been running it through it's paces and fully plan to
have it open to the closed beta group by next week. If you didn't hear
back from A
23 matches
Mail list logo
