As you may know, pinterest api seems down now.( api.pinterest.com )In this site: http://tijn.bo.lt/pinterest-api, it says that readonly access still works. What does exactly mean ?
I can build an application using this api but cannot use pinning or creating my own board ?
Sorry if my question is too ridiculous, i am very newbie to create an application with an API..
If the API permits read-only alone, that means you can consume data from the source, but you cannot write to it. You could probably get a list of items from your board, but you wouldn't be able to programmatically push a new item to your board.
It's a one-way road, until they open up another lane.
The information posted on that site is a bit out of date.
The API was until recently allowing read/write access, but about two weeks ago Pinterest stopped issuing new access tokens via their original authentication scheme. The new scheme requires API users to generate an oauth signature to receive an access token (needed to use the API), and consequently the API is only accessible to those who have received a client_id and client_secret for their application from Pinterest.
Caveat: if you happen to have an old access_key issued using the old API, you apparently can still use that to make API calls, though I'm guessing those tokens will expire soon.
Related
I'm going to make a project using the Google translate api and I'm thinking of uploading this project to a server and just sharing it with my friends. But unfortunately the Api Key that I will use in the project can be accessed clearly in the JavaScript file. This is a very bad situation. To prevent this, I have limited the Google Cloud Api and as far as I understand it is only allowed to be used on the links I allow. It cannot be used on other links. Now my main question is, is this method enough to protect Api from malicious people? Do I need to do anything else? Thank you in advance for your answers.
Best practice in these cases is to use .env files to keep data like API keys private.
You have to create a server for that which will perform OAuth and then send an API request to google.
You can get help about how to implement OAuth from this topic provided by google: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
If you send/attach your API key in frontend like javascript which is basically a frontend language then it can be used to:
Send fake requests which will use all of the bandwidth etc.
You should also consult the TOS.
On November 5th 2014 Google made some changes to the APIs terms of Service.
Like you I had an issue with the following line.
Asking developers to make reasonable efforts to keep their private
keys private and not embed them in open source projects.
That is however really only an issue if you are releasing the source code of your app as an Open source project for example.
If your just hosting this on a server then what you shoudl do is set up limitations for the api key adding_application_restrictions you can limit it so that the api key can only be used from your server and no where else.
I'm writing an app in JS that fetches Google Calendar events using Google Calendar API. I've already generated an API Key and Client ID - do I have to do something to try and 'secure' them? Their tutorial puts them directly in the JS file (https://developers.google.com/calendar/quickstart/js), but then I dig further into the dev docs (https://cloud.google.com/docs/authentication/api-keys#securing_an_api_key) and it says not to embed the API key into the code...but that could just be for paid API keys?
I'm writing this mini webapp for a class so I only need it to work for like 6 weeks. I'm hosting it via GitHub Pages, and it was the one that alerted me about the API Key when I pushed the code.
Bottom line - is it safe for me to embed the API key into the JS code that gets pushed to github and made publicly available (so I can have just a frontend and use GitHub Pages)? Or do I need to take some kind of preventative measures?
Thanks in advance!
Api key is only used for accessing public data. For example you could use it to access the Google Calendar public holiday calendars. That being said yes you should keep your api key secrete and not share it but google is aware that this is not possible with client side languages like JavaScript so i have never heard of anyone getting in trouble for leaking their api key by having it in a JavaScript application.
This warning is mainly means that you should not put it in a GitHub open source repository that anyone can download and then run. You must instruct people how to create their own.
That being said if you are trying to access private user data then you should be using Oauth2 to authenticate your users and this you can lock down to only your domain due to the need for a redirect uri. As you say you have created a client id i suspect that you have already done that. Apikey in the javascript code isnt strictly needed if you have added the client id for oauth2.
I have an API that I would like to restrict access to. I can provide access keys and check them with each request, but I'm not sure how far this is really going to go.
The API is used by applications, but it is also used by a web app which someone can just view the source of. If they did, they would have the key and could easily make API calls.
Is there a more reliable way to secure access? I'm not sure what the standard practice here is.
Edit: After thinking about it, I could use a two-prong approach. The web app can use POST with CSRF, and applications can use API keys. Any other ideas, or is this a generally accepted solution? (Note, this still wouldn't work for third-party web apps.)
Your API is never private since it's used by a web app which I am assuming is available to the general public. If this is the case, there really is no impetus to secure it since anyone and everyone would have access to the API.
If on the other hand, this web app is only available to registered users, you can use a token system to check for authorization. When the user successfully logs in, you pass back a token (usually something 20 to 30 characters long). Every API request would require a valid token. Tokens can be set to expire automatically (using a database job) X hours after creation if your application requires higher security thresholds. If security isn't a big issue, they can be renewed automatically every time a request is made.
This is essentially a two tiered approach. Temporary tokens are generated for users to directly connect to your API so that permanent credentials are never sent to the client. Predefined keys are given to third party developers who build applications on top of your API and have their own back-end.
If it's your API you can simply do this.
1) Insert the following code into your API file(s)
$authToken = "APItoken"; //variables
if( !isset($_REQUEST["authToken"]) || $_REQUEST["authToken"] != $authToken )
die("Need auth token");
2) You will now need to GET/POST/PUT the URL like this:
http://www.yoursite.com/api1.php?authToken=APItoken&nextParam=¶mAfterThat=
If this helped please mark it as the answer
EDIT:
Nevermind, read it wrong. Updating answer in a few minutes.
As of now I am building out a custom Tumblr page which is basically aggregating post content into 1 page.
Problem is, we can't use the Tumblr tags for the Like, we have successfully gotten the Reblog to work, but when ever I try and use an hrefed to this pattern,
'http://www.tumblr.com/like/'+oath+'?id='+id'
and /unlike/ for unliking the post.
I can't get anything but an access denied page to come up.. Shouldn't I at least be seeing an authentication pop-up of some kind? Not sure what else to do here. Need to get this LIKE functionality working, and using the Tumblr {like button} is not an option since we aren't using a {posts block} rather pulling all our content in via JSON API.
Found an answer!
So let me break it down for you all.. I am just going to run down all the issues and caveats that were discovered while I was hacking away at the Tumblr API. In most cases you will not find any of these answers on the inter webs. If you do, they most likely will just be my answers to my own questions that I posted to the Forums.
A Tumblr Application is defined by any page template either hosted
by Tumblr or not that will be using the Tumblr API. Applications
must be registered with Tumblr at:
https://www.tumblr.com/oauth/apps
All Tumblr Applications upon creation are given a set of keys for
accessing the Tumblr API. OAuth Consumer Key aka API Key Secret Key
The Tumblr API is divided mainly into two different types of
methods. The third being “Tagged” which is for pulling tagged posts
from the Blog or the User.
“Blog Methods” which only require the submission of the Consumer
Key. “User Methods” which require a full OAuth signed request which
meets the OAuth 1.0a Protocol. The “User Likes” returns a maximum of
50 records at a time. This is not documented in the Tumblr API
docs.
Currently the Tumblr API documentation directs developers to use one of the many open source API clients. However, all these clients seem to be Server Side applications. For providers, such as Tumblr, which support only OAuth1 or OAuth2 with Explicit Grant, the authentication flow needs to be signed with a secret key that may not be exposed in the browser.
HelloJS gets round this problem by the use of an intermediary webservice defined by oauth_proxy. This service looks up the secret from a database and performs the handshake required to provision an access_token. In the case of OAuth1, the webservice also signs subsequent API requests.
HelloJS - http://adodson.com/hello.js/ is the only client-side Oauth library that was available and free. There are many services out there that charge on a per-api hit basis to serve as a proxy.
The HelloJS OAuth Proxy is available at: https://auth-server.herokuapp.com/
Login to the OAuth Proxy is done using one of the following social account credentials: Google, Windows Live, Facebook, or Yahoo.
OAuth Proxy serves as a secure “man in the middle” allowing for the “Secret Key” to be securely stored while still allowing for Client-Side OAuth authentication.
HelloJS features a special Tumblr Module - http://adodson.com/hello.js/demos/tumblr.html
HelloJS utilizes the new Javascript Promises asynchronous functions specification - https://www.promisejs.org/
Javascript Promises have some unique rules when it comes to passing objects received from an asynchronous AJAX call.
With everything is done in the callback.
What jQuery calls a promise is in fact totally different to what everyone else calls a promise.
Hope this helps for future Tumblr integrations.
John
For my CMS component I'm implementing integration with Twitter API to fetch and display list of tweets (either connected to user or search query). I'm using Twitter Restful API v1.1, since the 1.0 version is going to be dropped in two months. Two interesting requests for me are user_timeline and search one.
Since my technology strongly relies on caching I need to avoid server-side processing as much as possible providing static html and piece of javascript. I've done it already for old version API and it worked fine. New approach however requires providing authentication data via OAuth. One of the property (oath_signature) is a hash of other properties (in which there are oauth_timestamp and oath_nonce, which should (should they?) be unique per each twitter request) and secret keys, thus make it unsecure to generate it on client side.
Is there any secure way to get list of tweets on client-side using new API?
The simple answer to your question is, "no, there is no secure way of doing this without server-side code." What I would do is set up a service to poll Twitter every xxxx seconds and retrieve the desired tweets. You should cache or store the results and then empty them each time you make your next request. If you are using C#, I have been working on a C# Twitter library that replicates Twitter's API and already has support for grabbing a user's timeline. I will be adding support for filter and search within the next two days (each one should take no more than ten minutes to implement, excluding testing, if you decide to do it yourself). You can reference this library in the service that I mentioned before.
If you do not have the server resources that you need for this, then I strongly caution you against using solutions that circumvent Twitter's intended securities, as it could leave you or your client in a vulnerable position.
You'll have to write a proxy web service on your server side. And as you say caching will be critical to avoid the 15 requests per 15 minutes for basic stuff like pulling tweets.
Definitely avoid doing any auth stuff on the front end. The new "application only" auth using OAuth 2 would allow you to embed bearer tokens in JavaScript meaning you don't need to do any of the signature stuff you're talking about. But don't. Anyone could use your bearer token and if your own users didn't exhaust the rate limit, other people stealing your token might.
If you don't have the server side resources to do this yoursefl, you might want to look at Flamingo. It'll do the auth and the caching for you, so you only need to work in JS like you used to.