I have some actions for Chrome OS that I would like to create using a background service. I am able to do one time setup but there will be no possibility for user interaction to authenticate in a browser for the calls during execution.
I've been reading through this Google documentation and found:
If the API you want to call has a service definition published in the [Google APIs GitHub repository][2], you can make authorized API calls using a JWT instead of an access token.
However, I can't seem to figure out what they mean by 'service definition' in that repository. Can someone help me understand where I find a list of APIs/actions that are available through these methods?
I also found this stackoverflow post which talks about using a refresh token. This was written a couple years ago - does anyone have insight into why this may be a BAD idea? I'm considering going this route but am not sure I fully understand all the implications of doing so. Essentially an admin would make a refresh token and load it into the application, where it could then be used to complete the background tasks for an indefinite amount of time (by refreshing the token in my service).
Related
I'm developing a Mac app that uses CloudKit as its back-end. Some of my users are requesting the ability to ingest and extract data via an automation/integration service such as Zapier. For this, I need to introduce a web API.
I am planning to use CloudKit Web Services to access the app's data. This data is user-specific and hence, resides in a private database. As a result, CloudKit requires user authentication as described here.
Essentially the user needs to be redirected to an Apple-hosted authentication page. After successful authentication, an authentication token is provided that can be used for data operations. Similar to how OAuth2 works, but different enough to not work with Zapier's (or probably any other similar services) supported authentication schemes.
Who has done something similar? What are my options? I want to keep things as simple as possible and make my web API's implementation as thin as possible.
Thanks.
Niels
This is definitely doable and you are on-track with your thinking. Here's how I envision it working:
You could do all of this with a front-end web app (no server-side app needed). I personally prefer Vue.js but you probably have something in mind already.
Your app will need to authenticate the user to CloudKit using the flow you mentioned. I highly recommend you use the Web Services API and not try to wrestle Apple's neglected CloudKit JS API. For this, you are going to need to generate an API token in the CloudKit Dashboard.
You app would then prompt the user to authenticate to Zapier.
You should now have user credentials for both CloudKit and Zapier in place in the user's browser cache (you can save, for example, the CloudKit token to sessionStorage and likewise with Zapier).
Make API calls to Zapier, pull down the data, and then save it to CloudKit all within your JS app. It's all API transactions at this point. I'm a fan of Axios for making the HTTP requests.
If you are downloading files, transacting huge amounts of data, or doing processor-intensive stuff, you might consider using a server for that work. But if you just need a place to pull and push reasonable chunks of data, I see no reason why you can't do it all in a front-end app.
Alternatively, if you don't want a web app at all, and want to only have the user work in the Mac app, that can be done, too. Just make API calls directly to Zapier from within your Cocoa app. Whether or not this is feasible depends some on how you want it to work.
If you have more specific questions or need help with any of the implementation details, feel free to add a follow-up comment or ask a new question.
Good luck!
I think the other answer is mostly correct. I don't know much about CloudKit, but we can talk through what you'd need for it to work.
Let's say you had a simple iOS app that stored contacts. On the iOS side, Apple presumably abstracts the upload and download operations.
If you wanted to make a web viewer for synced contacts using CloudKit, you'd need an endpoint to fetch all rows belonging to the authenticated user (each of which would have a UUID, name, and a phone number). I believe that's possible with CloudKit code Apple provides (but let me know if I'm off base).
Now, we want to integrate with Zapier. Say, a "New Contact" trigger. You make some sort of authenticated HTTP request from Zapier to Apple on behalf of an authenticated user. It gives back a list of contacts and Zapier can trigger on the ones it hasn't seen before. To do that, Zapier needs some sort of user token.
That's where the little front-end page the other answerer mentioned comes into play. If you've got a web page that can surface a user's token to them, they can paste it into Zapier and all of the above becomes possible. I'm not sure what the lifespan of the token is, but hopefully it can be automatically refreshed as needed (rather than the user needing to take any manual action).
I'm not sure if what I've described is possible, but do let me know if it is. It would be huge if it were possible to integrate Zapier and the iOS ecosystem!
Edit to respond to comments:
Zapier won't be able to interact with CloudKit in a way sufficient for me (some minor business logic is needed)
I'm not sure what that entails for you, but it's common to put logic in the Zapier integration to structure data in a way Zapier expects. There's a full Node.js execution environment, so the sky's the limit here.
I don't think Zapier can authenticate against CloudKit as it uses a non-standard authentication scheme
Once you've got a user's token (described above, which is unusual), you will almost certainly be able to use it in requests to cloudkit. Zapier provides a "custom" authentication scheme which lets you do basically anything you want. So unless Apple uses something that fetch can't handle (unlikely), it should be fine (once you get the token).
I would like to push data directly from my app into Zapier and have it done whatever magic the user has configured
This is also probably possible. Zapier ingests data in two ways:
polling, where Zapier frequently makes a web request, store the IDs of items we've seen before, and act on the new ones. You can read more about that here. Assuming you can work your business logic into the integration, this is doesn't require an external server besides Apple's
webhooks, where Zapier registers a subscription with you and you send new data, on demand, to that address. This would probably require a webserver on your end to handle. It's optional though - you can do polling instead.
Hopefully this cleared it up a bit. Feel free to reach out to partners#zapier.com and reference this question to talk more about it.
I would like to access my Google Drive account via their API inside of a Rails application. The idea is that I will store files, but I don't believe I need to implement any authorisation for it (like with Oauth2, for example), since I only want to access my account.
I have been researching for 2 days, but the Google documentation seems very confused and not very clear.
I started in vain with this guide https://developers.google.com/drive/api/v3/quickstart/ruby and tried to co-opt it for use inside of Rails, but since it relies on storing a token file returned upon authentication, I figured this wasn't really the right approach.
I don't have any code to share, just looking for some clarity on how I can achieve what I'm trying to do, or indeed if it's even possible.
Additional Info:
I'm using Devise for my own authentication, so implementing omniauth through that would be an option if it's necessary. I looked through some documentation around that which Devise has on their side, but I didn't want to go through that (it seemed like a lot) before knowing it was the correct course of action.
You need OAuth 2.0 to authorize requests on the Drive API as described on the documentation. In that link, you can find: «All requests to the Drive API must be authorized by an authenticated user».
To complete that authorization process, you should follow the instructions on the Drive API Ruby Quickstart linked on your question. Generating and saving a credentials.json for later use is the normal approach in this situation. Here you can read about using OAuth 2.0 over different scenarios.
I hope to have cleared your doubts on this topic, but feel free to ask further questions.
I'm working on a fairly basic Alexa skill that, in essence, searches through a specific Twitter feed looking for a hashtag, parses that tweet, and reads it back. The simplest way to do this seems to be using the Twitter API, since scraping appears to be against the TOS.
... crawling the Services is permissible if done in accordance with the provisions of the robots.txt file, however, scraping the Services without the prior consent of Twitter is expressly prohibited.
I've been having some trouble understanding how account linking works, as I've never dealt with OAuth before. I've been trying to follow the one tutorial around, but neither the text or video version were clear me.
Why the need for an external webapp?
...we need an OAuth implementation of our own to make the integration work correctly
What's wrong with the one provided by Twitter? Why can't any issues be fixed within the Lambda method, since the account integration isn't being touched otherwise AFAIK? Isn't having the tokens passed around via the URL a bad idea too? Their example code seems to require that the Consumer Secret be hard coded too.
Enter: “https://alexa-twitter-airport-info.herokuapp.com/oauth/request_token?vendor_id=XXXXXX&consumer_key=YYYYYY&consumer_secret=ZZZZZZ”.
At the very least, their webapp seems to be down for the time being, and it'd be nice to have an option that doesn't require paying money to host another copy.
I've seen this post discussing a Node.js OAuth implementation, but the necessity for such an implementation still escapes me.
Apologies for the oddly worded title, however I could not come up with a better one.
My application should be able to perform a limited set of actions on an Enterprise Google Apps system. Users submit requests to the application, the application interprets these requests and then makes requests to Google resources as necessary.The point is that users, who normally do not have permissions to access/modify the google apps resources, will be able to use this application to do so in the limited ways that it allows.
My problem lies in the apparent fact that the OAuth2.0 authorization flow seems designed to allow third party client applications to authorize themselves as the user and access/modify the user's google resources, rather than a global administrator's. In other words, a normal API key type deal. Unfortunately it seems that Google's AdminSDK will only work with OAuth2 authorization.
Is there a way to use Google's AdminSDK API with OAuth2 (permanent access token, maybe? API key?) to do what I want? Or is there a different API I should be trying? The now-deprecated Provisioning API seemed to be able to do this.
I feel like there should be a way for the application to just pull something out of a secrets.json or secrets.yml, include that in the API authorization request and have Google servers recognize and grant access to the application without the user ever needing to see what's going on.
For the record I'm using Ruby on Rails, though I don't think that affects the question very much.
Recently, YouTube decided to make video tags unavailable publicly. So to get the tags for a given video, I need to make an authenticated request to the API as the owner of the video. This is not a problem in my case as I'm fetching my own videos.
However, I'm confused about the authentication flow since YouTube strongly recommends to use OAuth2. Since I'm always going to authenticate as the same user (the owner of the video, aka myself), I definitely don't need to have any browser page for the actual user of the app to do anything. I see how I could have done it using ClientLogin (hardcoding login and password into the app) but I'm not sure how to approach this using OAuth2.
One last detail - that is not necessarily relevant since a high-level answer would be enough - is that I'm developing on iOS. Also I looked at this https://developers.google.com/accounts/docs/OAuth2 and particularly the web server case which seems closest to mine but was not able to get a clear idea from it.
Thanks in advance for your help and don't hesitate if you need me to be more specific.
There is no OAuth flow that supports your use case.
In general, you should not be distributing your YouTube login as part of your application. Even if this were available via ClientLogin, after a certain number of logins, you would likely be presented with a challenge because the authentication servers would detect a strange usage pattern.
OAuth is not for distribution a single user's login to a large N, where N is the number of users of your application. OAuth is meant for your application to act on behalf of an end user, and because tags are no longer exposed to end users through the UI, it does not make sense to expose them to users via the API either. More details can be found here:
http://apiblog.youtube.com/2012/08/video-tags-just-for-uploaders.html
How many videos do you have? What is the purpose for needing the tag metadata? From a pragmatic perspective, here are a few alternative implementations that would be easier and would not require users to log in as you:
Store a single file mapping video IDs to tags on a server somewhere and fetch this periodically. Google App Engine is a good place to do this.
Put the tag data in the description in a predictable format (you host the videos), and generate the metadata from this.