[twitter-dev] Re: OAuth example in Java language
On Wed, Jul 15, 2009 at 9:44 AM, hanlhohlho...@gmail.com wrote: I'm afraid no solution but the reason for the error is that the appengine does not allow opening a socket to or access to another host (http://code.google.com/appengine/docs/java/runtime.html#The_Sandbox) Access to other hosts is allowed via a URLConnection, which is sufficient for doing OAuth. So you can make it work. FWIW, I ended up hacking Signpost[1], but I don't recommend that solution[2]. I'd be interested to hear about any Java libraries that work out of the box. -cks [1] http://code.google.com/p/oauth-signpost/ [2] http://artofsystems.blogspot.com/2009/07/popstat-on-google-app-engine.html -- Christopher St. John http://praxisbridge.com http://artofsystems.blogspot.com
[twitter-dev] Re: Twitter Live Event Beaming
On Tue, Jul 7, 2009 at 10:25 PM, Juslin Guojuslin...@gmail.com wrote: I not sure if this is the place to ask this question. May i check does anyone know of a full-screen application/flash app/web-apps that allow me to beam on a projector/led screen live updates from twitter. I have an event where we would like to let the stadium audience twitter in. I'm not affiliated, but these guys are part of the developer community here in Dallas: http://ParaTweet.com/ If you've ever been at a conference with a backchannel projected behind a panel, you know how, uhh, unpredictable the audience can be, so Para Tweet allows moderation. -cks -- Christopher St. John http://praxisbridge.com
[twitter-dev] Re: Freelance Twitter API Dev directory?
And yet another: Twitter Username: @cks URL: http://artofsystems.blogspot.com URL: http://code.google.com/p/twasker/ Email: c...@praxisbridge.com Technology: Haskell/Cocoa :-) -- Christopher St. John http://artofsystems.blogspot.com
Re: OAuth Documentation Preview
On Tue, Feb 10, 2009 at 7:10 AM, Chris Scott cjscot...@gmail.com 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 are now logged in. I have no idea how this is done from a programming perspective, however, from a user perspective it works well IMHO. From a user perspective I find it confusing and awful. I second the chip hole in skull comment. I'd love to see some research on the topic, though, maybe it's just me.[1] 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. I too am thankful that plain-old-password-based auth is sticking around for when it's appropriate. -cks [1] Well, there was that link Cameron Kaiser posted: http://sites.google.com/site/oauthgoog/UXFedLogin/desktopapps but I mean some research that supports the idea that it's all fine and ok, not research that suggests it's an ugly hack that ruins usability. I especially liked the quote The flow makes some security people happy because the user never enters their password into the client application. However it makes usability much much worse, and any evil client application on most operating systems can do other evil things to the user's computer anyways such as installing malware.. Well, duh. Thanks for the link, Cameron. -- Christopher St. John http://artofsystems.blogspot.com
Re: This is why it's Urgent
On Mon, Jan 5, 2009 at 12:07 AM, Dale Merrick theunstable...@gmail.com wrote: What exactly is wrong with an application (for Mac OS X in this case) asking for a user's Twitter user name and password. Because your app could be evil[1], and, right now, a Twitter password is a non-expiring full-access read/write token. And somebody could tweet something evil while masquerading as you. Of course, you can always just change your password, but that's inconvenient. And there's a chance you use the same password for Twitter and your bank account. Have I really missed something important? Does this fever about apps asking for passwords apply to desktop and web apps, or just web apps? Logically, it's just as risky to give your password to an evil desktop app as it is to an evil web app (since the desktop app can always transmit the password to a remote server) However, most of the discussion has been about web apps. And yes, my app does inform the user that the password will be stored in the Keychain and it uses HTTPS when talking to the Twitter servers. To be fair, an evil app could just as easily say (and even do) that. -cks [1] In this contect, the word evil must be pronounced ala Time Bandits Mum! Dad! It's EVIL! Don't touch it!. http://www.youtube.com/watch?v=v60-qRvmzKA -- Christopher St. John http://artofsystems.blogspot.com
Re: A general status update from Twitter's API Team
On Tue, Dec 2, 2008 at 2:27 PM, Alex Payne [EMAIL PROTECTED] wrote: Additionally, Matt has been working with our User Experience (UX) team on a beta of OAuth support. The UX component of this work is almost complete, and we should be ready for our first deploy in the next week or ten days. Nifty. Anything y'all can share about the thinking behind your OAuth UX decisions would be very helpful (not just how it ends up looking, but the sorts of things that were of concern, differerent options you considered, etc). That stuff's pure gold for others facing similar sorts of decisions. Not totally on topic, I'm just saying... -cks -- Christopher St. John http://artofsystems.blogspot.com
