On a similar note (also brought up in a different thread I think) are the so-called "bot" accounts that many of us run for whatever reason. Now they will have to use OAuth to post instead of basic auth through things like curl. So, as the OP of that thread suggested, we'll have to create "dummy" umbrella apps for the bots just to get them a token, then store the tokens in the scripts running them I suppose.
Alas, @sockington will be subjected to the oauth cat/mouse game as well. more thinking out loud... -Chad On Sun, Mar 1, 2009 at 2:57 PM, Paul Kinlan <paul.kin...@gmail.com> wrote: > Thanks Chad, that is what I am trying to get across, we will definitely need > to drastically alter our workflows. > > I am definitely not trying to spread FUD, the problem is there is definitely > uncertainty about the process as a whole which I would like us all to talk > about and ways to work with (around) it. > > The main problems I have, like a lot of other people is that we developed > our apps using twitter as the authentication mechanism. It is very very > hard for us to now ask for our users to give us yet another password. I > personally never want to deal with managing users usernames and passwords. > > The perception is that oAuth will solve all authentication problems. I have > had this, where people won't use twe2 or twollo because we ask for your > password, and I generally agree with the sentiment - although the figure is > probably about 7 people in total. Now we have to ask every user for a "new" > password, and my gut feeling is that 90% of twitter users will not really > understand what oAuth is for (this doesn't mean we shouldn't have it) and > when we ask for a password I guarantee that most will use the same password > that they do for twitter, thus potentially negating everything oAuth is > meant for; or they will no longer decide to use the services. > > To see the workflow of oAuth on twe2 you can visit http://oauth.twe2.com > (please note, that like twitter oAuth, this is beta at the moment - also > note, the site isn't inline with the main site so it may not function as > expected). > > So anyway, this is a place where we can list our apps that we have created > that use Twitter as the authentication method and try and work out a decent > solution together. > > Thanks. > > Paul. > > > 2009/3/1 Chad Etzel <jazzyc...@gmail.com> >> >> This is an issue that concerns me as well, so thank you, Paul, for >> bringing it up on this list. I do not consider if FUD. This is >> something that at least a few of us would like to discuss. If it >> doesn't pertain to you, then fine. >> >> My example would be TweetGrid. Right now, it is entirely a "drive-by" >> site, meaning that anyone can use it w/o having to sign-in to the site >> itself and there is no need to create an account or have any notion of >> a session. People can search at will. If they want to actually >> interact with twitter, then (for now, until the official oauth switch) >> they enter their username and password for whatever account they'd >> like to use for the interaction and all is well. This is especially >> nice for people with multiple accounts since there is no "session" on >> tweetgrid, each twitter interaction is handled as a separate >> event/action, so you can change your "active account" at any time >> trivially by just retyping your user/pass in the appropriate boxes. >> >> With OAuth I see this changing quite a bit. Each twitter account that >> wants to interact with twitter through TweetGrid would need to make >> the loop through twitter. So, if someone wants to use 4 or 5 accounts >> at once they'd make 4 or 5 authentication trips to twitter and back. >> Imagine having to do that every time you come to use TweetGrid. I >> imagine this being a UX nightmare unless I implement some sort of user >> logon/session system which stores oauth keys for authenticated >> accounts, etc. Then it is no longer a fully drive-by service, and now >> I have to bring a login system/database into the equation. >> >> Please Note: This is not me complaining... this is me thinking >> outloud for the benefit of myself and Paul, who originally posed the >> question. Responses telling me to "man up and just deal with it" will >> be promptly forwarded to /dev/null. I have been thinking for a while >> about how to solve this UX situation and how to create something that >> won't alienate users by making them create Yet Another Website Account >> (tm) and jumping through some hoops to get there. >> >> Anyway, those are my current thoughts. I, too, would be interested to >> hear how sites/applications that currently don't use a login system >> are planning on dealing with the oauth change. >> >> -Chad >> >> On Sun, Mar 1, 2009 at 1:34 PM, Dossy Shiobara <do...@panoptic.com> wrote: >> > >> > On 3/1/09 1:28 PM, Petermdenton wrote: >> >> >> >> Dossy, serioulsy, no one is saying the sky is falling. This list is for >> >> application developers to discuss development topics as they please. >> >> You >> >> may know everything, but for those of us who wish to discuss >> > >> > We need to resist spreading FUD. Twitter has its problems, but creating >> > ones where there aren't any helps no one. >> > >> > -- >> > Dossy Shiobara | do...@panoptic.com | http://dossy.org/ >> > Panoptic Computer Network | http://panoptic.com/ >> > "He realized the fastest way to change is to laugh at your own >> > folly -- then you can let go and quickly move on." (p. 70) >> > > >
