WTF is this mailing list being piped to http://igooglefriends.blogspot.com/ ???
I know they're probably jacking the RSS feed and postifying it, but sheesh. -chad On Sun, Mar 1, 2009 at 4:09 PM, Paul Kinlan <paul.kin...@gmail.com> wrote: > Alternatively, you could store the Token (optionally with symmetric key > encryption) as a cookie in the user's browser. Done intelligently, the > user's browser could store multiple such cookies in various chips, one for > each identity they control and have authorized. > > That is pretty reasonable until the cookie expires, in which case the user > would have to re-allow the application access to their data. This is the > option I have been toying with the most, however in a previous thread it has > been suggested that this is not the supported use of oAuth. > > My point being that it is not oAuth that is the problem, it is that there > are lots of apps out there that will now need to add new account management > systems and new passwords etc. > > 2009/3/1 Dossy Shiobara <do...@panoptic.com> >> >> On 3/1/09 2:22 PM, Chad Etzel wrote: >>> >>> So, if someone wants to use 4 or 5 accounts >>> at once they'd make 4 or 5 authentication trips to twitter and back. >> >> Sure, once per OAuth token lifetime. If Twitter implements OAuth >> correctly, it's supposed to work like this: >> >> User "Sue" uses third-pary Application "App". App needs to access Twitter >> API on behalf of Sue. App sends Sue through the OAuth flow, where Twitter >> authenticates Sue and confirms that Sue is granting App permission to act on >> her behalf. Twitter returns App an OAuth "Token" which it must store (more >> on this later) in order to make requests on Sue's behalf. App can use and >> reuse Token until Token's lifetime expires, at which point App must send Sue >> through the OAuth flow again. >> >> To ensure a reasonably sane UX for Sue, Twitter needs to permit a >> reasonably sane Token lifetime. _Ideally_, Twitter should allow users to >> select their desired lifetime (one hour, one day, one week, one year, for >> example), in addition to a UX flow to revoke a valid OAuth Token. >> >> Now, on the subject of "storing" the Token: yes, you could create your own >> private authentication database and associate the Token to said credentials. >> Alternatively, you could store the Token (optionally with symmetric key >> encryption) as a cookie in the user's browser. Done intelligently, the >> user's browser could store multiple such cookies in various chips, one for >> each identity they control and have authorized. >> >> Does this help? Can we stop worrying and love the bomb, now? >> >> -- >> 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) > >
