Hi Alex,

Thanks for the prompt reply.  I was really keen on never to have store
credentials for our service (i.e, have credentials to log in to our site -
it means we don't have to have an account creation process and we don't have
to securly store extra usernames and passwords).  Our cookies will be long
lived, however there is no guarantee.  I like the idea of seamlessly
authenticating against twitter as essentially twitter is the most important
part of twe2.

Kind Regards,
Paul.

2009/2/17 Alex Payne <a...@twitter.com>

>
> We discourage any workflow that frequently sends users to Twitter to
> re-authorize an OAuth application. This really isn't the way OAuth is
> intended to be used.
>
> As to your second point: yes, do NOT store keys in unencrypted cookies.
>
> On Tue, Feb 17, 2009 at 12:54, Paul Kinlan <paul.kin...@gmail.com> wrote:
> > Hi Alex,
> >
> > Erm, yes and no.  I understand from our service point of view that we can
> > hold on to the access key for as long as it is valid, however, we are
> trying
> > to create a no username system so we need to keep track of our own
> > session/auth cookies, which could get cleared out regularly.  What
> happens,
> > then is that to log in we will need to send them to the twitter authorise
> > app to access the data each time they clear their cookies.  So my
> question,
> > is it acceptable?  I think it is, just wondering if you guys "support"
> this.
> >
> > One other question I am presuming the access keys should never be exposed
> > publically?  For instance it would not be a good idea to store the key in
> a
> > cookie (we are not doing this anyway).
> >
> > Kind Regards,
> > Paul Kinlan.
> >
> > 2009/2/17 Alex Payne <a...@twitter.com>
> >>
> >> Our access tokens should be long-lived enough that users shouldn't
> >> have to come back to Twitter. Does that answer your question?
> >>
> >> On Sat, Feb 14, 2009 at 00:39, Paul Kinlan <paul.kin...@gmail.com>
> wrote:
> >> > Hi Guys,
> >> >
> >> > I am working developing twe2's oAuth support and I have a quick
> question
> >> > for
> >> > the group.  Obviously, oAuth solves us having to store the twitter-ers
> >> > username and password on our system by delegating the authentication
> out
> >> > to
> >> > twitter, however, for the past couple of services I have created, the
> >> > twitter username and password has been the only form of identification
> >> > on
> >> > our services, basically meaning that there is no seperate login
> account
> >> > for
> >> > our service.
> >> >
> >> > So my question is it acceptable whenever the users' sessions on our
> site
> >> > expires to redirect the user to the oAuth "allow twe2 access" page at
> >> > twitter if they need to login to our site? Obviously if they never
> login
> >> > to
> >> > the site again the access_token may still be valid (unless they remove
> >> > our
> >> > app from their account) and the backend software still works like
> >> > normal,
> >> > but if they re-accept our application this will refresh the access
> token
> >> > but
> >> > I am ok with that.
> >> >
> >> > On a side note, the "Allow Access" page says the following "The
> >> > application
> >> > Twe2 by Twe2 Limited would like the ability to access and update your
> >> > data
> >> > on Twitter".  We are read only application it should read "The
> >> > application
> >> > Twe2 by Twe2 Limited would like the ability to access your data on
> >> > Twitter"
> >> >
> >> > Kind Regards,
> >> > Paul Kinlan
> >> >
> >> > Twe2 Ltd - www.twe2.com
> >> >
> >>
> >>
> >>
> >> --
> >> Alex Payne - API Lead, Twitter, Inc.
> >> http://twitter.com/al3x
> >
> >
>
>
>
> --
> Alex Payne - API Lead, Twitter, Inc.
> http://twitter.com/al3x
>

Reply via email to