I'm making a Twitter application that makes one Twitter account echo another.
I used the http://dev.twitter.com tool to obtain the access token associate with one account, but since only one person can administer a Twitter application I can't get an access token for any other accounts.
It would appear I have to build an entire 3-legged-oauth strategy only to get one access token!
https://dev.twitter.com/docs/auth/obtaining-access-tokens
How can I most easily acquire an access token for the other user? I don't need a strategy to get many of them, just one.
Okay so I found the answer after a few hours of searching.
You can do it fastest using the PIN auth method and you'll never have to do it again.
Additionally, this gist contains some awesome Ruby code so I didn't have to do any coding, and I got my access token right from the command line:
https://gist.github.com/mirakui/388067
Cheers.
Related
I'm using omniauth to authenticate a user via Google. When the user logs in via Google, I check if an account already exists with the same email (if it does, I reject sign in).
When I create the new User model, I give it the name, email, and the URL of the user's 'image'. I am not sure how to dynamically update the information in my database when the user changes their settings on Google, including the image_url when they change their profile image.
A good example of this scenario is this Stack Overflow; I signed up to SO with Google. Having changed my profile image (recently), I was surprised to find that my old Google image remains attached to my SO profile. Maybe it takes time for Google to change the old URL to represent the new image. I have noticed that some parts of Google use my new image, and other parts continue to use my old. Of course, this question doesn't have much to do with Google's profile image mechanism, I just think this is a perfect example.
My questions are:
Should I want to do this, or should I instead provide the user the ability to change their details through my site, completely ignoring what happens to their Google profile?
If I should do this, what is the best way? Checking on every login isn't ideal as the user might not log out for days or even weeks.
Should I be storing the Google auth token? Currently, I'm not as I don't need to make any Google API calls -- I only use OAuth for the 'uid' to ensure it's the same account logging in (the email isn't used at all).
I don't think the answer will be "don't store user info, query Google instead", so I'm not really sure what best practice is in this scenario. A brief walkthrough on proper procedure would be very helpful.
Normally, oauth applications will use the endpoint /me.json as part of the login process: After the user is signed in, the app uses that fresh token to query their profile info right away and update data. In your case, I understand you ignore when email already exists. You should probably add a new step there, to update your local record if it already exists instead of purely ignoring it.
In other words, your app wont be automatically notified if users change their profile pictures. But you can always use their log in action to fetch the latest image (or use their token in a background job that runs every n periods of time using something like cron + whenever, assuming the oauth scope authorizes offline access)
I'm working on a cloud-storage API, authorized via OAuth. Users of third-party applications can permit said application to access their files/data via our RESTful API.
Currently, we are limiting a third-party app access to a users account once. E.g., the Access Token table has a UNIQUE on the consumer column and the user column. This makes sense at first glance, as the user should never be sent to our service to authorize a third-party application twice, since the third-party would already know their user is already tied to our service and wouldn't need to be re-authorized.
However, what if this user has two accounts on the third-party app, and they want said app to connect to their single account on our service twice? This seems likely, given the prevalence of multiple accounts on services such as Reddit.
Here are the possible solutions I've come up with so far, none of them being perfect:
Display an error during the second auth request: This seems like a frustrating experience for the user, a "cop out" of sorts.
Delete the previous token: This would likely annoy the user, as their previous accounts stop working. Even if we display a warning, it would likely be hard to explain what exactly is happening.
Return the same access token as the first request: Each time the access is requested, a set of permissions are also passed along. The permissions for the second request could be different than the permissions for the first request. Also, not sure if this will violate the OAuth spec, as the secondly generated Request Token isn't tied to the Access Token properly.
Allow two to be generated: This would be confusing, as when the user visits their screen full of authorized applications to revoke one, they don't know which authorization is tied to which third-party account. We could ask for an optional third-party username parameter when the Request Token is generated to identify the different auth's (we currently ask for a non-OAuth-standard permission parameter already). But, this seems like it wouldn't be used by 99% of developers and could make application development more confusing.
What is the best way to handle this situation? Is there a standardized practice for handling this use-case?
I think your last case is the right way to go - Allow two to be generated
When the user visits his screen full of authorized application, it's not necessary to show him one and the same Application twice - you just have to delete the tokens associated with the app if the user revokes application access. That is, all his authorizations to the app with all tokens will go away with the revoke, which is fine.
Im writing a web-app that gives our customers the possibility to SYNC their files on their personal Google Drive onto OUR bushiness application. (only limited file types).
So - what works so far:
Users signup to the app, (using OAuth2 and saves a refreshtoken in my end) the user/and my app, have now access to files on their Drive, and can manually invoke file transfers.
Working fine.
Users can afterwards login again and repeat this without having to authenticate the app again. Fine.
In parallel, I need some kind "service" that loops thru our app's user-base and AUTOMATICALLY syncs files in a designated folder - say every 10 mins.
Now im running into problems because of OAuth2 model, needs to redirect to authenticate every user. But I cannot make multiple redirects out of a single request to, say "/SyncAllUsers".
Also, when testing with one user only, the user still have to be logged in into the browser session, or else google will redirect to the service-login page.
(We use a chron-job to invoke these methods at a specified interval - and it is working well with dropbox-accounts, and these users also use OAuth)
So basically 2 questions:
How can I access my users Drive accounts, with my already authorized app, without having users to "be logged in"
And how should I handle the sync-service to run without having to redirect at every user.
I have spent days searching for answers on https://developers.google.com/drive/ and in here.
I have impl. the OAuth code from here https://developers.google.com/drive/credentials#retrieve_oauth_20_credentials
and I modified it so it is using my own user-database.
For your infomation im using the Client ID for web applications, in Google APIs Console
Once you have the refresh token, you can use it to perform synchronization without user intervention. This is the nature of offline access and the whole purpose of a refresh token.
(Sorry if this doesn't answer your question, I am not exactly sure what you are asking, so please explain more and I will try to give you a different/better answer.)
My goal is to use these bundles to connect to MailChimp OAuth or Facebook (not necessarily as a login option but that could come later - right now just want my app authorized to access the MailChimp API) - I've got the whole process somewhat working in the sense that I can be redirect to MailChimp or Facebook, allow my app and the I am always redirected to to my failur_path as defined in my security.yml. I presume this is correct behavior since I do not have users with the matching tokens. My question is... how do I create these users in the first place? Or rather how do I get the provided oauth token into the user's data for later user/authentication?
Thanks
I know it's old, but in case someone didn't find it:
https://gist.github.com/danvbe/4476697
as I started to work with Twitterizer in order to publish on someone's wall I am in confusing time.
There is a page, my case, DefaultTwitter.aspx where is link to authenticate on twitter with token provided. Goes on Twitter and comes back to CallbackTwitter.aspx with outh_token and secret. And so the user is identified. On twitterizer example says:
Step 5 - Store the results
You should now store the access token and the user details. Keep in mind that the
only way an access token will become invalid is if the user revokes access by logging
into Twitter. Otherwise, those values will grant you access to that user's data
forever.
My questions are: - should I store any data in SQL datatable and what exactly(however I hope that is not the case to do so)
somebody said that I should save in a cookie(I thought in session); however then if another user comes then how should I create a button to logout or something like that?
-how will user revoke application access if he would like so?
A live example will be much appreciated as I could not found any on internet how exactly twitter api works.
When your application finishes getting authorization to access the user's data, the result is the access token (represented by 2 values, a key and a secret). Those values are, in effect, the username/password you can use in requests to the API on behalf of that user.* Save those values in your SQL database. You'll also be given the user id and screen name. It's probably a good idea to keep those handy, too.
The user can revoke access to an application by going to http://twitter.com/settings/applications, finding the application and clicking the revoke access button next to it. Your application cannot revoke access for the user.
You asked for an example, but you're citing the example application. Just look at the source code in that sample.
* - That's a simplification for explanation sake. Please don't crucify me, OAuth experts.