Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add application-only auth support #48

Closed
wants to merge 1 commit into from
Closed

Add application-only auth support #48

wants to merge 1 commit into from

Conversation

mdeschamps
Copy link

No description provided.

@mdeschamps
Copy link
Author

@sferik @ryangreenberg hey guys, I know that you've been looking at application-only authentication for Twurl. I put up this PR with support Guest too. Let me know what you think and if we can merge this so others in my team (@ twitter) can use it. Thanks

@caniszczyk
Copy link
Contributor

cc: @sferik for any commentary

@@ -1,6 +1,7 @@
module Twurl
class RCFile
FILE = '.twurlrc'
APP_ONLY_PROFILE = 'app-only'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I’m not happy about hardcoding this.

@sferik
Copy link
Contributor

sferik commented Aug 1, 2014

Overall, this looks fine, however it’s a somewhat different approach from what @ryangreenberg and I agreed upon after some discussion in #47. I’m open to this approach—working, tested code trumps jibber-jabber every time—however, I have a concern about overloading the username in the configuration file.

Specifically, this issue is still unaddressed:

One unsolved problem of this approach is how to distinguish between application-authenticated clients and user-authenticated clients in the twurl accounts view and how to switch between them, since you could have the same client ID associated with both. I think this is a solvable problem but it could make things more confusing.

In other words, what happens if try to authorize a client to be used in “app-only mode” and then authorize the same client in “user mode”? Ideally, I’d like users to be able to use a single client, with and without the --guest flag. I appreciate the effort to keep the .twurlrc file backward-compatible but positive deltas should be fine.

Curious to hear what @ryangreenberg thinks about this solution and whether this solves his use-case, since he’s the one who initially raised the issue.

@mdeschamps
Copy link
Author

@sferik Hi Erik, thanks for taking a look. And sorry I didnt look at #47 before, it was until I posted this PR that I saw it.

And I think this approach incidentally solves exactly that issue, because by having a 'app-only' profile we can switch between user auth and app-only auth on the same consumer key. We could put them all together in the same user's profile but right now, I am using app-only I dont even have to accept the PIN or anything like that because it is not linked to my account at all.

example:

twurl authorize --consumer-key XXX --consumer-key YYY

in the .twurlrc file you will see something like

profiles
  username:
    XXX:
      consumer_key: XXX
      .....

then you can use the same key for app-only

twurl authorize --consumer-key XXX --consumer-key YYY --app-only

in the .twurlrc file you will see something like

profiles:
  manuel:
    XXX:
      consumer_key: XXX
      .....
  app-only
    XXX:
      consumer_key: XXX
      .....

And now I can toggle between both auth methods using:

twurl set default manuel XXX
twurl /1.1/statuses/home_timeline.json

or

twurl set default app-only XXX
twurl /1.1/statuses/home_timeline.json  #will fail, no user
twurl /1.1/statuses/user_timeline.json?screen_name=twitterapi   #success

@mdeschamps mdeschamps closed this Mar 10, 2016
@smaeda-ks smaeda-ks mentioned this pull request Dec 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants