Sorry, there is currently no way to accomplish this.
Nor should there be... there is NO way that any site other than
Twitter should control my login status on Twitter.
Now to the OP's question:
When I logged out from my application, I need to logout from
twitter also.
What _you_ can do is
Thanks for your response. The problem lies not with my application
security, but with the security of the twitter account of my users.
Imagine this:
1. User comes to my application and signs in with Twitter.
2. This forces the user to log into Twitter (force_login=true)
3. The user is redirected
Hey GHengeveld,
There was a conversation about this back in April which might be help
[1]. In it Taylor explains that OAuth is stateless and that the logged
in state of a user is based on your system rather than ours.
Your application would be interacting with Twitter using the OAuth
tokens for
yeah thanks
Just curious why that isn't displayed as an option in my Application
details page...
Might cause some confusion for anyone who hasn't read the wiki in
detail.
Oauth/authenticate was added later and I guess the application detail page
was never updated.
Abraham
On Tue, Jan 19, 2010 at 17:29, eco_bach bac...@gmail.com wrote:
yeah thanks
Just curious why that isn't displayed as an option in my Application
details page...
Might cause some confusion
Thanks Ryan
On Jan 17, 5:38 pm, ryan alford ryanalford...@gmail.com wrote:
1. Desktop applications are those that are installed or ran from a PC
/Mac/Linux or on a mobile device. They are outside of the browser.
2. One is used for web applications, the other is for desktop applications.
3.
On Thu, 6 Aug 2009 08:50:05 -0700 (PDT)
Dewald Pretorius dpr...@gmail.com wrote:
If I understand you correctly, you're saying one should login for the
user in the OAuth process? Wouldn't that involve scraping the Twitter
web interface? Or am I outside the ballpark with my understanding?
I'm
Jesse,
Amen to that.
When one does customer support for long enough, you quickly realize
that:
a) People do not read instructions, and
b) Many people are not as computer literate as you'd wish them to be.
If you send people all over the place, many go, WTF, and abandon the
process out of
It's a subtle distinction: users aim to use the application, not the
Twitter website. They expect Twitter to ask for their permission, but
they don't expect to start using the Twitter website. So they're a
little surprised when Twitter asks them to log in. The page doesn't
make it clear that
On Thu, 6 Aug 2009 05:09:48 -0700 (PDT)
Dewald Pretorius dpr...@gmail.com wrote:
Amen to that.
When one does customer support for long enough, you quickly realize
that:
a) People do not read instructions, and
b) Many people are not as computer literate as you'd wish them to be.
If
Chris,
If I understand you correctly, you're saying one should login for the
user in the OAuth process? Wouldn't that involve scraping the Twitter
web interface? Or am I outside the ballpark with my understanding?
Dewald
On Aug 6, 10:36 am, Chris Babcock cbabc...@kolonelpanic.com wrote:
On
Some users aren't comfortable giving their Twitter password to another
website. For them, it's sort of a good thing to be sent to Twitter's
I would hazard a guess that they really are the long tail. Only a
small percentage of people would care, most would not but they are
going to be penalized
I would agree, this area needs some TLC as my post suggested:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/0f57965561504a1c?hl=en
If your users don't understand why they're seeing the Twitter login
screen, then your application needs to do a better job of explaining
it.
On Aug 4, 2:05 pm, John Kristian jmkrist...@gmail.com wrote:
a user who's focused on the application won't see the
first page and wonder, Why must I log
On Wed, Aug 5, 2009 at 7:32 AM, Duane Roelands duane.roela...@gmail.comwrote:
If your users don't understand why they're seeing the Twitter login
screen, then your application needs to do a better job of explaining
it.
Duane I don't think this has anything to do with that. Having worked on
Hi
No it will not expired/ invalid you can store it in DB or cookie
On Mon, Jul 20, 2009 at 4:33 PM, CG learn@gmail.com wrote:
Hi all, I have a newbie question would like to seek the confirmation
from experienced twitter app developer ... hopefully somebody can
help .
I would
What about the pin?(for desktop clients) How long will it be accessible.
Regards
Srikanth
On Mon, Jul 20, 2009 at 4:54 PM, Mandakini kumari pkumar...@gmail.comwrote:
Hi
No it will not expired/ invalid you can store it in DB or cookie
On Mon, Jul 20, 2009 at 4:33 PM, CG
The pin is only required to exchange the request token for the access token.
After you have an access token the pin is useless.
Abraham
On Mon, Jul 20, 2009 at 07:06, srikanth yaradla
srikanth.yara...@gmail.comwrote:
What about the pin?(for desktop clients) How long will it be
accessible.
On Sun, Jul 12, 2009 at 20:54, Scott Carter scarter28m-goo...@yahoo.comwrote:
I am using as a reference the Sign in with Twitter documentation at:
http://apiwiki.twitter.com/Sign-in-with-Twitter
When I issue an authenticate call to:
If you want to give your users the ability to use multiple twitter accounts
with your service, Authorize allows them a chance to switch accounts during
the login flow. We consciously do that on a couple of our apps.
On Sun, Jul 12, 2009 at 10:02 PM, Abraham Williams 4bra...@gmail.comwrote:
On
On Sun, Jul 12, 2009 at 11:27 PM, Wynn
Netherlandwynn.netherl...@gmail.com wrote:
If you want to give your users the ability to use multiple twitter accounts
with your service, Authorize allows them a chance to switch accounts during
the login flow. We consciously do that on a couple of our
Hi all,
So it looks like that the token being returned to the callback from
oauth/authenticate is now the same request token we sent. Can someone
please confirm this? This is the last message I found on the topic.
If this is the case, how are we supposed to proceed? Should we
exchange the
Adding this to the wiki. Thanks for sharing!
Thanks,
Doug
--
Doug Williams
Twitter Platform Support
http://twitter.com/dougw
On Fri, May 1, 2009 at 12:54 AM, jmathai jmat...@gmail.com wrote:
Did a quick write up on using PHP to sign in to Twitter.
Working Example:
Was there an announcement that this was going down? I'm seeing This feature
is temporarily disabled as well.
Jesse
On Sun, Apr 19, 2009 at 4:05 AM, Rore rotem.her...@gmail.com wrote:
Any idea when authenticate url will work again?
On Apr 17, 4:31 pm, Matt Sanford m...@twitter.com wrote:
Any idea when authenticate url will work again?
On Apr 17, 4:31 pm, Matt Sanford m...@twitter.com wrote:
Hi all,
This behavior (i.e. which token is returned) is likely to change
soon. Once again, stay tuned for updates.
— Matt
On Apr 17, 2009, at 01:02 AM, Abraham Williams wrote:
It just dawned on me: it looks like /oauth/authenticate is designed to
merely deliver a user's ID and screen_name to a application, not to
authorize the application to access Twitter on the user's behalf. Is
that so?
A suggestion: treat the user ID and screen_name as a resource that's
protected
I'm having trouble using /oauth/authenticate, too. After
authenticating, Twitter redirects back to my consumer with a different
oauth_token than the one I sent to initiate authentication. Twitter
APIs don't accept either token. Sending the original request token
to /oauth/access_token elicits
The oauth_token returned from oauth/authenticate is the key from the users
access tokens. as long as you store the access tokens you can match the
returned oauth_token with what is in your database.
On Fri, Apr 17, 2009 at 01:35, John Kristian jmkrist...@gmail.com wrote:
I'm having trouble
Zac, this can be solved just be properly modeling user accounts and
twitter accounts.
It should be one-to-many. Signing in with any of their twitter
accounts can sign in that user.
Let me know if that doesn't address your problem.
Ivan
http://tipjoy.com
On Apr 16, 1:18 pm, Zac Bowling
Ivan, that doesn't solve the original problem of getting those
accounts authenticated.
Zac, you should just use the /oauth/authorize link instead. the
/oauth/authenticate link is what will do the auto-redirect.
-Chad
On Thu, Apr 16, 2009 at 1:45 PM, Ivan Kirigin ivan.kiri...@gmail.com wrote:
Sorry, a little confused by your email. :-)
It's really not directly related to twitter sign-on directly but
with OAuth authentication in general that doesn't force the user to
authenticate each time.
The problem is with all OAuth providers that shortcut the process of
associating and granting
That is why there are 2 methods:
1) Authorize that always displays prompt on Twitter.
2) Authenticate that shows nothing if already signed in and authorized.
Use them based on your needs.
Something to keep in mind that OAuth is not designed for identity
authentication. It is designed for data
On 4/16/09 12:55 PM, Doug Williams wrote:
Related: More OAuth documentation is to come throughout the day so
some of the links will be broken. It's a glaring omission in the
documentation.
Let's use this thread to fill the holes people find while implementing
Sign in with Twitter for the time
Hi Dossy,
The initial token required is a RequestToken rather than an
AccessToken. Making the request for the RequestToken requires you know
the consumer key/secret and (a) let's us know what application this is
for (callback_url alone would not) and (b) prevent the token-shooting
On Thu, Apr 16, 2009 at 13:26, Dossy Shiobara do...@panoptic.com wrote:
On 4/16/09 12:55 PM, Doug Williams wrote:
Related: More OAuth documentation is to come throughout the day so
some of the links will be broken. It's a glaring omission in the
documentation.
Let's use this thread to
On 4/16/09 2:33 PM, Matt Sanford wrote:
The initial token required is a RequestToken rather than an AccessToken.
Making the request for the RequestToken requires you know the consumer
key/secret and (a) let's us know what application this is for
(callback_url alone would not) and (b) prevent
Awesome this will definitely improve the process. In particular the
users will only have to face the question of Deny or Allow access
only once.
The only problem I foresee is if multiple users use the same computer.
This way if USERA is already signed in to Twitter and USERB attempts
to log into
On 4/16/09 2:33 PM, Matt Sanford wrote:
The initial token required is a RequestToken rather than an
AccessToken. Making the request for the RequestToken requires you know
the consumer key/secret and (a) let's us know what application this is
for (callback_url alone would not) and (b)
On Apr 16, 9:52 am, Doug Williams d...@twitter.com wrote:
Matt has deployed our answer for one click login. It requires only a small
change to the normal Twitter OAuth workflow and is documented here:
http://apiwiki.twitter.com/Sign-in-with-Twitter
This is the perfect tool for web
Hello again,
We've discussed OpenID but adding it is not something we can do
in the near-term. With OAuth just out the door we felt like this was a
better user experience than have to continually re-display the Accept/
Deny dialog. I'm looking into a few issues raised in this thread
Allen,
OAuth is the third-party authorization protocol that we have decided to
embrace. You can search the group's archives [1] for past discussion on
OpenID and the Twitter API.
1.
An idea is to have the oauth/authorize page display login/don't login
instead of accept/deny if the user has already approved the application.
On Thu, Apr 16, 2009 at 16:29, djMax djm...@gmail.com wrote:
Did this stop working? All of the sudden I'm getting 500 server
errors back. Was
42 matches
Mail list logo
